Emergency data management and access system

ABSTRACT

Described herein are systems, servers, devices, methods, and media for providing and managing access to emergency data. In some embodiments, a method for managing access to emergency data for emergency service providers by an emergency management system includes the steps of: determining a first set of data categories to be made accessible to an emergency service provider (ESP), wherein the first set of data categories is selected from a second set of data categories; detecting an emergency alert from an electronic device; associating the ESP with the emergency alert; gathering emergency data associated with the emergency alert available for the first set of data categories; and securely transmitting, to the ESP, the emergency data associated with the emergency alert available for the first set of data categories.

CROSS-REFERENCE

This application claims the benefit of U.S. Provisional Application No.62/658,357, filed Apr. 16, 2018, which application is incorporatedherein by reference.

BACKGROUND

A person in an emergency may request help using a mobile communicationdevice such as a cell phone to dial a designated emergency number like9-1-1 or a direct access phone number for a local emergency serviceprovider (e.g., an emergency dispatch center). This emergency call isassigned to one or more first responders by the emergency serviceprovider. To dispatch emergency personnel to aid the person in theemergency, the emergency service provider must determine the location ofthe emergency. However, these communications are typically limited toaudio calls with narrow functionality because most emergency serviceproviders that receive emergency calls currently lack the capacity formore sophisticated communications. Accordingly, emergency serviceproviders are typically limited to verbally receiving emergencylocations from the person in the emergency during the emergency call.Unfortunately, there are a great many instances in which a person in anemergency does not know or is otherwise incapable of articulating theirlocation. With technological advances, the amount and types of data,which may provide situational awareness about emergencies, has expandedconsiderably. Therefore, there is a need for managing access to data foremergency response.

SUMMARY OF THE INVENTION

One advantage provided by the systems, servers, devices, methods, andmedia of the instant application is the ability to gather and deliverdevice-based hybrid locations (hereinafter, “enhanced locations”) andadditional data that may be pertinent to emergency situations toemergency service providers (ESPs; e.g., public safety answering points,fire departments, police departments, paramedics, police officers,etc.). In some embodiments, an emergency management system (EMS)includes a clearinghouse (also referred to as an “EmergencyClearinghouse”) that functions to receive enhanced locations andadditional data from various sources and at various times before,during, or after emergency situations and distribute enhanced locationsand additional data to ESPs to aid the ESPs in responding to liveemergency situations. In some embodiments, the enhanced locations andadditional data are delivered by the EMS to the ESP at a public safetyanswering point (PSAP). In some embodiments, the enhanced locations andadditional data are displayed within a preexisting ESP system, such asan Automatic Location Identification (ALI) display. In some embodiments,the enhanced locations and additional data are displayed through awindow (also referred to as an “Enhanced Data Window”) within a desktopapplication installed at the ESP.

Another advantage provided by the systems, servers, devices, methods,and media of the instant application is the ability to allow ESPadministrators to control the types of data delivered from the EmergencyClearinghouse and received by an ESP. In some embodiments, the EMSincludes an emergency data management portal (hereinafter, “managementportal”) that receives a selection of one or more ESPs and a selectionof one or more types of data to be delivered to the one or more ESPsduring an emergency. In some embodiments, at the management portal, anESP administrator selects one or more ESPs from a plurality of ESPsunder the ESP administrator's authority. In some embodiments, at themanagement portal, an ESP administrator defines one or more roles withinan individual ESP and selects one or more types of data to be deliveredfrom the Emergency Clearinghouse to the one or more roles within theindividual ESP. In some embodiments, the management portal is furtherused to upgrade an ESP without requiring the installation of new oradditional hardware or software. For example, as new types of databecome available to or provided by the Emergency Clearinghouse, an ESPadministrator can access the management portal to select the new typesof data to be delivered to the ESPs under the ESP administrator'sauthority.

Another advantage provided by the systems, servers, devices, methods,and media of the instant application is the ability to access anemergency response application provided to authorize emergency serviceproviders (ESPs) for receiving and displaying emergency data, such asenhanced locations, and accessing a management portal to manage orcustomize roles within an ESP. In some embodiments, the emergencyresponse application functions to verify emergency service providers,generate emergency data requests, and display emergency data receivedfrom the Emergency Clearinghouse, as described below. In someembodiments, the emergency response application includes a managementportal, as described below. In some embodiments, the emergency responseapplication provides a graphical user interface to a computing devicethat is accessible by members of emergency service providers. In someembodiments, the emergency response application integrates with one ormore preexisting ESP systems to provide a seamless and comprehensiveemergency data delivery system.

Another advantage provided by the systems, servers, devices, methods,and media of the instant application is the ability to dynamicallyvisualize emergency data (e.g., enhanced locations and additional data)to further aid ESPs in responding to emergency situations. ESPpersonnel, such as a call taker at a PSAP, are often required to makequick decisions in high pressure situations. While access to additionaldata may help ESP personnel make better informed decisions, siftingthrough additional information may take additional time. Therefore, itis useful to display additional information to ESPs in advantageousways. In some embodiments, a dynamic visualization is applied toemergency data at an enhanced data window at an ESP. In someembodiments, the dynamic visualization emphasizes different elements ofemergency data at different times during an emergency. In someembodiments, the dynamic visualization is applied to the emergency databy highlighting, bolding, enlarging, underlining, moving, or coloringthe emergency data. In some embodiments, the dynamic visualization iscustomizable through settings in the corresponding role defined by theESP administrator. In some embodiments, the dynamic visualization iscustomizable by a user such as the ESP personnel who utilizes theemergency data when responding to emergency calls.

In various embodiments, described herein are systems, servers, devices,methods, and media for providing and managing access to emergency data.In one aspect, disclosed herein is a method for managing access toemergency data for emergency service providers by an emergencymanagement system, the method comprising: a) determining a first set ofdata fields to be made accessible to an emergency service provider(ESP), wherein the first set of data fields is selected from a secondset of data fields; b) detecting an emergency alert from an electronicdevice; c) associating the ESP with the emergency alert; d) gatheringemergency data associated with the emergency alert available for thefirst set of data fields; and e) securely transmitting, to the ESP, theemergency data associated with the emergency alert available for thefirst set of data fields. In some embodiments, the method furthercomprises receiving an emergency data request from the ESP; and securelytransmitting the emergency data associated with the emergency alert tothe ESP in response to receiving the emergency data request. In someembodiments, the emergency data request comprises credentials associatedwith the ESP; and determining the first set of data fields to be madeaccessible to the ESP further comprises verifying the credentialsassociated with the ESP. In some embodiments, gathering emergency datafurther comprises obtaining ingestion data from one or more electronicdevices associated with a user of the electronic device, wherein: theingestion data comprises location data, user data, or sensor data; theingestion data is marked with data sources; and the emergency datasecurely transmitted to the ESP is restricted to a particular datasource. In some embodiments, the method further comprises: at amanagement portal: receiving selection of the ESP by an administrator ofthe ESP; displaying the second set of data fields; and receivingselection of the first set of data fields from the second set of datafields, wherein the first set of data fields is a subset of the secondset of data fields. In some embodiments, the ESP is selected from aplurality of ESPs by the administrator of the ESP. In some embodiments,the method further comprises: at a management portal: receivingcredentials from the administrator of the ESP; validating thecredentials from the administrator of the ESP; and providing access tothe management portal to the administrator of the ESP in response tovalidating the credentials from the administrator of the ESP. In someembodiments, the management portal is a web application. In someembodiments, the method further comprises: at a management portal:receiving definition of a role for the ESP; displaying the second set ofdata fields; and receiving selection of the first set of data fields tobe accessible for the role from the second set of data fields, whereinthe first set of data fields is a subset of the second set of datafields. In some embodiments, the method further comprises providing adata display to the ESP; receiving credentials from the ESP;identifying, based on the credentials, the ESP as having the role; anddisplaying the emergency data securely transmitted to the ESP throughthe data display. In some embodiments, the management portal is distinctfrom the data display wherein the emergency data associated with theemergency alert is displayed. In some embodiments, the ESP is associatedwith the emergency alert using a phone number associated with theelectronic device. In some embodiments, the method further comprisesdisplaying the emergency data transmitted to the ESP through a datadisplay. In some embodiments, the method further comprises applying adynamic visualization to the emergency data associated with theemergency alert displayed through the data display. In some embodiments,applying the dynamic visualization further comprises displaying the datafields included in the first set of data fields sequentially in separategroups. In some embodiments, the data fields included in the first setof data fields are displayed sequentially according to a predeterminedtiming schedule. In some embodiments, applying the dynamic visualizationfurther comprises emphasizing a data field. In some embodiments,emphasizing a data field further comprises highlighting, bolding,enlarging, underlining, moving, or coloring the data field. In someembodiments, the dynamic visualization is applied in response to userinput at the ESP. In some embodiments, the dynamic visualization isapplied in response to contextual cues detected during an emergencysession associated with the emergency alert. In some embodiments, themethod further comprises determining a data source for the emergencydata associated with the emergency alert available for the first set ofcategories; and transmitting, to the ESP, only the emergency dataassociated with the emergency alert available for the first set of datafields received from the data source. In some embodiments, the methodfurther comprises receiving an emergency data request from the ESP,wherein the emergency data request comprises credentials associated withthe ESP and provided to the ESP by a software vendor. In someembodiments, determining the first set of data fields to be madeaccessible to the ESP further comprises verifying the credentialsassociated with the ESP. In some embodiments, transmitting the emergencydata associated with the emergency alert to the ESP further comprisestransmitting the emergency data associated with the emergency alertthrough a network provided by the software vendor. In some embodiments,the method further comprises displaying the emergency data associatedwith the emergency alert through a data display, wherein the datadisplay is accessed through a desktop application provided by thesoftware vendor. In some embodiments, the emergency data request fromthe ESP is generated by the ESP in response to the ESP receiving theemergency alert. In some embodiments, the emergency data request fromthe ESP is generated in response to user input at the ESP. In someembodiments, the data display is a web page accessed through a desktopapplication. In some embodiments, the data display is selected from atab within the desktop application. In some embodiments, the datadisplay is selected from a tool button within the desktop application.In some embodiments, the method further comprises updating the datadisplay when new emergency data associated with the emergency alertavailable for the first set of data fields is received by the emergencymanagement system. In some embodiments, the emergency data associatedwith the emergency alert is received from the electronic device. In someembodiments, the emergency data associated with the emergency alert isgenerated by the electronic device. In some embodiments, the emergencydata associated with the emergency alert is generated by a secondelectronic device communicatively coupled to the electronic device. Insome embodiments, the emergency data associated with the emergency alertis generated by a second electronic device associated with a user of theelectronic device. In some embodiments, the second electronic device isa vehicle, wearable, or IoT device. In some embodiments, the emergencydata associated with the emergency alert is generated by a mobileapplication installed on the electronic device. In some embodiments, thefirst set of data fields comprises one or more of photo, name, address,date of birth, phone number, gender, height, weight, ethnicity,languages spoken, occupation, email, notes, emergency contacts,allergies, blood type, disabilities, existing conditions, andmedications. In some embodiments, the first set of data fields comprisesone or more of caller phone number, probable civic address, probablecivic address likelihood, last location update time, latitude andlongitude, uncertainty radius, confidence, and altitude. In someembodiments, the first set of data fields comprises an audio or videofeed. In some embodiments, the audio or video feed is received from anIoT device associated with a user of the electronic device. In someembodiments, the audio or video feed is received from an IoT devicecommunicatively coupled to the electronic device. In some embodiments,the audio or video feed is received from the electronic device. In someembodiments, the emergency alert is an emergency call made from a mobilephone. In some embodiments, the method further comprises securelytransmitting the emergency data associated with the emergency alert toan electronic device associated with an emergency responder. In someembodiments, the method further comprises displaying the emergency dataassociated with the emergency alert on the electronic device associatedwith the emergency responder. In some embodiments, the emergency alertcomprises one of: an emergency wireless call, an emergency landlinecall, a text call, and an emergency call back. In some embodiments, thedata source is a mobile application installed on the electronic device.In some embodiments, the data source is a second electronic devicecommunicatively coupled to the electronic device. In some embodiments,the data source is a second electronic device associated with a user ofthe electronic device. In some embodiments, the second electronic deviceis a vehicle, wearable, or IoT device.

In another aspect, disclosed herein is a method for managing access toemergency data for emergency service providers by an emergencymanagement system, the method comprising: a) detecting an emergencyalert from an electronic device; b) gathering emergency data associatedwith the emergency alert; c) identifying an emergency service provider(ESP) associated with the emergency alert; d) determining a set of datafields selected to be made accessible to the ESP; and e) transmitting,to the ESP, the emergency data associated with the associated with theemergency alert available for the set of data fields.

In another aspect, disclosed herein is a method for managing access toemergency data for emergency service providers by an emergencymanagement system, the method comprising: a) at a management portal: i)receiving selection of an emergency service provider (ESP) by anadministrator of the ESP; ii) displaying a first set of data fields; andiii) receiving selection by the administrator of the ESP of a second setof data fields to be made accessible to the ESP from the first set ofdata fields, wherein the second set of data fields is a subset of thefirst set of data fields; b) detecting an emergency alert from anelectronic device; c) receiving an emergency data request for theemergency alert from the ESP; d) determining the second set of datafields selected by the administrator of the ESP to be made accessible tothe ESP; e) gathering emergency data associated with the emergency alertavailable for the second set of data fields; and f) transmitting, to theESP, the emergency data associated with the emergency alert availablefor the second set of data fields. In some embodiments, the emergencydata associated with the emergency alert is gathered from one or moredata sources and associated with the emergency alert using a phonenumber associated with the emergency alert. In some embodiments, a datasource within the one or more data sources is a second electronic devicecommunicatively coupled to the electronic device. In some embodiments,the second electronic device is a vehicle, wearable, or IoT device. Insome embodiments, a data source within the one or more data sources is amobile application installed on the electronic device. In someembodiments, the emergency data request comprises credentials associatedwith the EPS; and determining the second set of data fields furthercomprises verifying the credentials associated with the ESP. In someembodiments, the method further comprises: at the management portal:receiving credentials from the administrator of the ESP; validating thecredentials from the administrator of the ESP; and providing access tothe management portal to the administrator of the ESP in response tovalidating the credentials from the administrator of the ESP. In someembodiments, the method further comprises: a) at the management portal:i) receiving definition of a role for the ESP; ii) displaying the secondset of data fields; and iii) receiving selection by the administrator ofthe ESP of a third set of data fields to be made accessible for the rolefrom the second set of data fields, wherein the third set of data fieldsis a subset of the second set of data fields; b) identifying the ESP ashaving the role; and c) transmitting, to the ESP, emergency dataassociated with the emergency alert available for the third set of datafields. In some embodiments, the emergency data request comprises anidentifier of the role; and determining the second set of data fieldsfurther comprises referencing the identifier of the role with themanagement portal. In some embodiments, the method further comprisesproviding an enhanced data display through a desktop applicationinstalled on a computing device at the ESP; and displaying the emergencydata transmitted to the ESP through the enhanced data display. In someembodiments, the management portal is a web application accessed by aURL; and the enhanced data display is a webpage accessed through thedesktop application installed on the computing device at the ESP. Insome embodiments, the method further comprises applying a dynamicvisualization to the emergency data transmitted to the ESP displayedthrough the enhanced data display. In some embodiments, the dynamicvisualization further comprises emphasizing a data field; andemphasizing a data field further comprises highlighting, bolding,enlarging, underlining, moving, or coloring the data field. In someembodiments, the dynamic visualization is applied in response to userinput at the ESP. In some embodiments, the emergency alert is anemergency call made from a mobile device.

In another aspect, disclosed herein is a system for managing access toemergency data for emergency providers, the system comprising: a) anetwork server; b) an emergency service provider (ESP) communicativelycoupled to the network server; c) an electronic device communicativelycoupled to the network server and configured to generate an emergencyalert; and d) an emergency management system (EMS) communicativelycoupled to the network server and configured to: i) determine a firstset of data fields to be made accessible to the ESP, wherein the firstset of data fields is selected from a second set of data fields; ii)detect the emergency alert from the electronic device; iii) associatethe ESP with the emergency alert; iv) gather emergency data associatedwith the emergency alert available for the first set of data fields; andv) securely transmit, to the ESP, the emergency data associated with theemergency alert available for the first set of data fields. In someembodiments, the EMS is further configured to receive an emergency datarequest from the ESP; and securely transmit the emergency dataassociated with the emergency alert to the ESP in response to receivingthe emergency data request. In some embodiments, the emergency datarequest comprises credentials associated with the ESP; and the EMS isfurther configured to verify the credentials associated with the ESP. Insome embodiments, the EMS is further configured to gather emergency databy obtaining ingestion data from one or more electronic devicesassociated with a user of the electronic device, wherein: the ingestiondata comprises location data, user data, or sensor data; the ingestiondata is marked with data sources; and the emergency data securelytransmitted to the ESP is restricted to a particular data source. Insome embodiments, the EMS is further configured to provide a managementportal configured to receive selection of the ESP by an administrator ofthe ESP; display the second set of data fields; and receive selection ofthe first set of data fields from the second set of data fields, whereinthe first set of data fields is a subset of the second set of datafields. In some embodiments, the ESP is selected from a plurality ofESPs by the administrator of the ESP. In some embodiments, themanagement portal is further configured to receive credentials from theadministrator of the ESP; validate the credentials from theadministrator of the ESP; and provide access to the management portal tothe administrator of the ESP in response to validating the credentialsfrom the administrator of the ESP. In some embodiments, the managementportal is a web application. In some embodiments, the EMS is furtherconfigured to provide a management portal configured to receivedefinition of a role for the ESP; display the second set of data fields;and receive selection of the first set of data fields to be accessiblefor the role from the second set of data fields, wherein the first setof data fields is a subset of the second set of data fields. In someembodiments, the EMS is further configured to receive credentials fromthe ESP; identify, based on the credentials, the ESP as having the role;and provide a data display configured to display the emergency datasecurely transmitted to the ESP. In some embodiments, the managementportal is distinct from the data display wherein the emergency dataassociated with the emergency alert is displayed. In some embodiments,the ESP is associated with the emergency alert using a phone numberassociated with the electronic device. In some embodiments, the EMS isfurther configured to provide a data display configured to display theemergency data securely transmitted to the ESP. In some embodiments, thedata display is further configured to apply a dynamic visualization tothe emergency data associated with the emergency alert displayed throughthe data display. In some embodiments, the dynamic visualizationcomprises displaying the data fields included in the first set of datafields sequentially in separate groups. In some embodiments, the datafields included in the first set of data fields are displayedsequentially according to a predetermined timing schedule. In someembodiments, the dynamic visualization comprises emphasizing a datafield. In some embodiments, emphasizing a data field further compriseshighlighting, bolding, enlarging, underlining, moving, or coloring thedata field. In some embodiments, the data display is configured to applythe dynamic visualization to the emergency data displayed through thedata display in response to user input at the ESP. In some embodiments,the data display is configured to apply the dynamic visualization to theemergency data displayed through the data display in response tocontextual clues detected during an emergency session associated withthe emergency alert. In some embodiments, the EMS is further configuredto determine a data source for the emergency data associated with theemergency alert available for the first set of categories; and transmit,to the ESP, only the emergency data associated with the emergency alertavailable for the first set of data fields received from the datasource. In some embodiments, the EMS is further configured to receive anemergency data request from the ESP, wherein the emergency data requestcomprises credentials associated with the ESP and provided to the ESP bya software vendor; verify the credentials associated with the ESP;transmit the emergency data associated with the emergency alert througha network provided by the software vendor; and provide a data displayconfigured to display the emergency data transmitted to the ESP. In someembodiments, the ESP is configured to generate the emergency datarequest in response to the ESP receiving the emergency alert. In someembodiments, the ESP is configured to generate the emergency datarequest in response to user input at the ESP. In some embodiments, thedata display is a web page accessed through a desktop application. Insome embodiments, the data display is selected from a tab within thedesktop application. In some embodiments, the data display is selectedfrom a tool button within the desktop application. In some embodiments,the EMS is further configured to update the data display when newemergency data associated with the emergency alert available for thefirst set of data fields is received by the EMS. In some embodiments,the electronic device is further configured to transmit the emergencydata associated with emergency alert to the EMS. In some embodiments,the electronic device is further configured to generate the emergencydata associated with the emergency alert to the EMS. In someembodiments, the electronic device is further configured to receive theemergency data associated with the emergency alert from a secondelectronic device communicatively coupled to the electronic device. Insome embodiments, the EMS is further configured to receive the emergencydata associated with the emergency alert from a second electronic deviceassociated with a user of the electronic device. In some embodiments,the second electronic device is a vehicle, wearable, or IoT device. Insome embodiments, the EMS is further configured to receive the emergencydata associated with the emergency alert from a mobile applicationinstalled on the electronic device. In some embodiments, the first setof data fields comprises one or more of photo, name, address, date ofbirth, phone number, gender, height, weight, ethnicity, languagesspoken, occupation, email, notes, emergency contacts, allergies, bloodtype, disabilities, existing conditions, and medications. In someembodiments, the first set of data fields comprises one or more ofcaller phone number, probable civic address, probable civic addresslikelihood, last location update time, latitude and longitude,uncertainty radius, confidence, and altitude. In some embodiments, thefirst set of data fields comprises an audio or video feed. In someembodiments, the EMS is further configured to receive the audio or videofeed from an IoT device associated with a user of the electronic device.In some embodiments, the EMS is further configured to receive the audioor video feed from an IoT device communicatively coupled to theelectronic device. In some embodiments, the EMS is further configured toreceive the audio or video feed from the electronic device. In someembodiments, the emergency alert is an emergency call made from a mobilephone. In some embodiments, the EMS is further configured to transmitthe emergency data associated with the emergency alert to an electronicdevice associated with an emergency responder. In some embodiments, theEMS is further configured to display the emergency data associated withthe emergency alert on the electronic device associated with theemergency responder. In some embodiments, the emergency alert comprisesone of: an emergency wireless call, an emergency landline call, a textcall, and an emergency call back. In some embodiments, the data sourceis a mobile application installed on the electronic device. In someembodiments, the data source is a second electronic devicecommunicatively coupled to the electronic device. In some embodiments,the data source is a second electronic device associated with a user ofthe electronic device. In some embodiments, the second electronic deviceis a vehicle, wearable, or IoT device.

In another aspect, disclosed herein is a system for managing access toemergency data for emergency service providers, the system comprising:a) a network server; b) an emergency service provider (ESP)communicatively coupled to the network server; c) an electronic devicecommunicatively coupled to the network server and configured to generatean emergency alert; and d) an emergency management system (EMS)communicatively coupled to the network server and configured to: i)detect the emergency alert from the electronic device; ii) gatheremergency data associated with the emergency alert; iii) identify anemergency service provider (ESP) associated with the emergency alert;iv) determining a set of data fields selected to be made accessible tothe ESP; and v) transmit, to the ESP, the emergency data associated withthe associated with the emergency alert available for the set of datafields.

In another aspect, disclosed herein is a system for managing access toemergency data for emergency service providers, the system comprising:a) a network server; b) an emergency service provider (ESP)communicatively coupled to the network server; c) an electronic devicecommunicatively coupled to the network server and configured to generatean emergency alert; and d) an emergency management system (EMS)communicatively coupled to the network server and configured to: i)provide a management portal configured to: 1) receive selection of theESP by an administrator of the ESP; 2) display a first set of datafields; and 3) receive selection by the administrator of the ESP of asecond set of data fields to be made accessible to the ESP from thefirst set of data fields, wherein the second set of data fields is asubset of the first set of data fields; ii) detect an emergency alertfrom the electronic device; iii) receive an emergency data request forthe emergency alert from the ESP; iv) determine the second set of datafields selected by the administrator of the ESP to be made available tothe ESP; v) gather emergency data associated with the emergency alertavailable for the second set of data fields; and vi) transmit, to theESP, the emergency data associated with the emergency alert availablefor the second set of data fields. In some embodiments, the EMS isfurther configured to gather the emergency data associated with theemergency alert from one or more data sources and associate theemergency data with the emergency alert using a phone number associatedwith the emergency alert. In some embodiments, a data source within theone or more data sources is a second electronic device communicativelycoupled to the electronic device. In some embodiments, the secondelectronic device is a vehicle, wearable, or IoT device. In someembodiments, a data source within the one or more data sources is amobile application installed on the electronic device. In someembodiments, the emergency data request comprises credentials associatedwith the ESP; and the EMS is further configured to verify thecredentials associated with the ESP. In some embodiments, the EMS isfurther configured to provide a management portal configured to receivecredentials from the administrator of the ESP; validate the credentialsfrom the administrator of the ESP; and provide access to the managementportal to the administrator of the ESP in response to validating thecredentials from the administrator of the ESP. In some embodiments, theEMS is further configured to: a) provide a management portal configuredto: i) receive definition of a role for the ESP; ii) display the secondset of data fields; and iii) receive selection of a third set of datafields by the administrator of the ESP to be accessible for the rolefrom the second set of data fields, wherein the third set of data fieldsis a subset of the second set of data fields; b) identify the ESP ashaving the role; and c) transmit, to the ESP, emergency data associatedwith the emergency alert available for the third set of data fields. Insome embodiments, the emergency data request comprises an identifier ofthe role; and the EMS is further configured to reference the identifierof the role with the management portal. In some embodiments, the EMS isfurther configured to provide an enhanced data display to the ESPthrough a desktop application installed on a computing device at theESP; and display the emergency data transmitted to the ESP through theenhanced data display. In some embodiments, the management portal is aweb application accessed by a URL; and the enhanced data display is awebpage accessed through the desktop application installed on thecomputing device at the ESP. In some embodiments, the enhanced datadisplay is further configured to apply a dynamic visualization to theemergency data transmitted to the ESP displayed through the enhanceddata display. In some embodiments, the dynamic visualization emphasizinga data field; and emphasizing a data field further compriseshighlighting, bolding, enlarging, underlining, moving, or coloring thedata field. In some embodiments, the enhanced data display is configuredto apply the dynamic visualization to the emergency data displayedthrough the data display in response to user input at the ESP. In someembodiments, the emergency alert is an emergency call made from a mobiledevice.

In another aspect, disclosed herein is a non-transitory computerreadable storage media encoded with a computer program includinginstructions executable by at least one processor for: a) determining afirst set of data fields to be made accessible to an emergency serviceprovider (ESP), wherein the first set of data fields is selected from asecond set of data fields; b) detecting an emergency alert from anelectronic device; c) associating the ESP with the emergency alert; d)gathering emergency data associated with the emergency alert availablefor the first set of data fields; and e) securely transmitting, to theESP, the emergency data associated with the emergency alert availablefor the first set of data fields. In some embodiments, the media furtherincludes instructions for receiving an emergency data request from theESP; and securely transmitting the emergency data associated with theemergency alert to the ESP in response to receiving the emergency datarequest. In some embodiments, the emergency data request comprisescredentials associated with the ESP; and determining the first set ofdata fields to be made accessible to the ESP further comprises verifyingthe credentials associated with the ESP. In some embodiments, gatheringemergency data further comprises obtaining ingestion data from one ormore electronic devices associated with a user of the electronic device,wherein: the ingestion data comprises location data, user data, orsensor data; the ingestion data is marked with data sources; and theemergency data securely transmitted to the ESP is restricted to aparticular data source. In some embodiments, the media further includesinstructions for: at a management portal: receiving selection of the ESPby an administrator of the ESP; displaying the second set of datafields; and receiving selection of the first set of data fields from thesecond set of data fields, wherein the first set of data fields is asubset of the second set of data fields. In some embodiments, the ESP isselected from a plurality of ESPs by the administrator of the ESP. Insome embodiments, the media further includes instructions for: at themanagement portal: receiving credentials from the administrator of theESP; validating the credentials from the administrator of the ESP; andproviding access to the management portal to the administrator of theESP in response to validating the credentials from the administrator ofthe ESP. In some embodiments, the management portal is a webapplication. In some embodiments, the media further includesinstructions for: at the management portal: receiving definition of arole for the ESP; displaying the second set of data fields; andreceiving selection of the first set of data fields to be accessible forthe role from the second set of data fields, wherein the first set ofdata fields is a subset of the second set of data fields. In someembodiments, the media further includes instructions for providing adata display to the ESP; receiving credentials from the ESP;identifying, based on the credentials, the ESP as having the role; anddisplaying the emergency data securely transmitted to the ESP throughthe data display. In some embodiments, the management portal is distinctfrom the data display wherein the emergency data associated with theemergency alert is displayed. In some embodiments, the emergency alertusing a phone number associated with the electronic device. In someembodiments, the media further includes instructions for displaying theemergency data transmitted to the ESP through a data display. In someembodiments, the media further includes instructions for applying adynamic visualization to the emergency data associated with theemergency alert displayed through the data display. In some embodiments,applying the dynamic visualization further comprises displaying the datafields included in the first set of data fields sequentially in separategroups. In some embodiments, the data fields included in the first setof data fields are displayed sequentially according to a predeterminedtiming schedule. In some embodiments, applying the dynamic visualizationfurther comprises emphasizing a data field. In some embodiments,emphasizing a data field further comprises highlighting, bolding,enlarging, underlining, moving, or coloring the data field. In someembodiments, the dynamic visualization is applied in response to userinput at the ESP. In some embodiments, the dynamic visualization isapplied in response to contextual cues detected during an emergencysession associated with the emergency alert. In some embodiments, themedia further includes instructions for determining a data source forthe emergency data associated with the emergency alert available for thefirst set of categories; and transmitting, to the ESP, only theemergency data associated with the emergency alert available for thefirst set of data fields received from the data source. In someembodiments, the media further includes instructions for receiving anemergency data request from the ESP, wherein the emergency data requestcomprises credentials associated with the ESP and provided to the ESP bya software vendor. In some embodiments, determining the first set ofdata fields to be made accessible to the ESP further comprises verifyingthe credentials associated with the ESP. In some embodiments,transmitting the emergency data associated with the emergency alert tothe ESP further comprises transmitting the emergency data associatedwith the emergency alert through a network provided by the softwarevendor. In some embodiments, the media further includes instructions fordisplaying the emergency data associated with the emergency alertthrough a data display, wherein the data display is accessed through adesktop application provided by the software vendor. In someembodiments, the emergency data request from the ESP is generated by theESP in response to the ESP receiving the emergency alert. In someembodiments, the emergency data request from the ESP is generated inresponse to user input at the ESP. In some embodiments, the data displayis a web page accessed through a desktop application. In someembodiments, the data display is selected from a tab within the desktopapplication. In some embodiments, the data display is selected from atool button within the desktop application. In some embodiments, themedia further includes instructions for updating the data display whennew emergency data associated with the emergency alert available for thefirst set of data fields is received by the emergency management system.In some embodiments, the emergency data associated with the emergencyalert is received from the electronic device. In some embodiments, theemergency data associated with the emergency alert is generated by theelectronic device. In some embodiments, the emergency data associatedwith the emergency alert is generated by a second electronic devicecommunicatively coupled to the electronic device. In some embodiments,the emergency data associated with the emergency alert is generated by asecond electronic device associated with a user of the electronicdevice. In some embodiments, the second electronic device is a vehicle,wearable, or IoT device. In some embodiments, the emergency dataassociated with the emergency alert is generated by a mobile applicationinstalled on the electronic device. In some embodiments, the first setof data fields comprises one or more of photo, name, address, date ofbirth, phone number, gender, height, weight, ethnicity, languagesspoken, occupation, email, notes, emergency contacts, allergies, bloodtype, disabilities, existing conditions, and medications. In someembodiments, the first set of data fields comprises one or more ofcaller phone number, probable civic address, probable civic addresslikelihood, last location update time, latitude and longitude,uncertainty radius, confidence, and altitude. In some embodiments, thefirst set of data fields comprises an audio or video feed. In someembodiments, the audio or video feed is received from an IoT deviceassociated with a user of the electronic device. In some embodiments,the audio or video feed is received from an IoT device communicativelycoupled to the electronic device. In some embodiments, the audio orvideo feed is received from the electronic device. In some embodiments,the emergency alert is an emergency call made from a mobile phone. Insome embodiments, the media further includes instructions for securelytransmitting the emergency data associated with the emergency alert toan electronic device associated with an emergency responder. In someembodiments, the media further includes instructions for displaying theemergency data associated with the emergency alert on the electronicdevice associated with the emergency responder. In some embodiments, theemergency alert comprises one of: an emergency wireless call, anemergency landline call, a text call, and an emergency call back. Insome embodiments, the data source is a mobile application installed onthe electronic device. In some embodiments, the data source is a secondelectronic device communicatively coupled to the electronic device. Insome embodiments, the data source is a second electronic deviceassociated with a user of the electronic device. In some embodiments,the second electronic device is a vehicle, wearable, or IoT device.

In another aspect, disclosed herein is a non-transitory computerreadable storage media encoded with a computer program includinginstructions executable by at least one processor for: a) detecting anemergency alert from an electronic device; b) gathering emergency dataassociated with the emergency alert; c) identifying an emergency serviceprovider (ESP) associated with the emergency alert; d) determining a setof data fields selected to be made accessible to the ESP; and e)transmitting, to the ESP, the emergency data associated with theassociated with the emergency alert available for the set of datafields.

In another aspect, disclosed herein is a non-transitory computerreadable storage media encoded with a computer program includinginstructions executable by at least one processor for: a) at amanagement portal: i) receiving selection of an emergency serviceprovider (ESP) by an administrator of the ESP; ii) displaying a firstset of data fields; and iii) receiving selection by the administrator ofthe ESP of a second set of data fields to be made accessible to the ESPfrom the first set of data fields, wherein the second set of data fieldsis a subset of the first set of data fields; b) detecting an emergencyalert from an electronic device; c) receiving an emergency data requestfor the emergency alert from the ESP; d) determining the second set ofdata fields selected by the administrator of the ESP to be madeaccessible to the ESP; e) gathering emergency data associated with theemergency alert available for the second set of data fields; and f)transmitting, to the ESP, the emergency data associated with theemergency alert available for the second set of data fields. In someembodiments, the emergency data associated with the emergency alert isgathered from one or more data sources and associated with the emergencyalert using a phone number associated with the emergency alert. In someembodiments, a data source within the one or more data sources is asecond electronic device communicatively coupled to the electronicdevice. In some embodiments, the second electronic device is a vehicle,wearable, or IoT device. In some embodiments, a data source within theone or more data sources is a mobile application installed on theelectronic device. In some embodiments, the emergency data requestcomprises credentials associated with the EPS; and determining thesecond set of data fields further comprises verifying the credentialsassociated with the ESP. In some embodiments, the media further includesinstructions for: at the management portal: receiving credentials fromthe administrator of the ESP; validating the credentials from theadministrator of the ESP; and providing access to the management portalto the administrator of the ESP in response to validating thecredentials from the administrator of the ESP. In some embodiments, themedia further includes instructions for: a) at the management portal:receiving definition of a role for the ESP; displaying the second set ofdata fields; and receiving selection by the administrator of the ESP ofa third set of data fields to be made accessible for the role from thesecond set of data fields, wherein the third set of data fields is asubset of the second set of data fields; b) identifying the ESP ashaving the role; and c) transmitting, to the ESP, emergency dataassociated with the emergency alert available for the third set of datafields. In some embodiments, the emergency data request comprises anidentifier of the role; and determining the second set of data fieldsfurther comprises referencing the identifier of the role with themanagement portal. In some embodiments, the media further includesinstructions for providing an enhanced data display through a desktopapplication installed on a computing device at the ESP; and displayingthe emergency data transmitted to the ESP through the enhanced datadisplay. In some embodiments, the management portal is a web applicationaccessed by a URL; and the enhanced data display is a webpage accessedthrough the desktop application installed on the computing device at theESP. In some embodiments, the media further includes instructions forapplying a dynamic visualization to the emergency data transmitted tothe ESP displayed through the enhanced data display. In some embodimentsthe dynamic visualization further comprises emphasizing a data field;and emphasizing a data field further comprises highlighting, bolding,enlarging, underlining, moving, or coloring the data field. In someembodiments, the dynamic visualization is applied in response to userinput at the ESP. In some embodiments, the emergency alert is anemergency call made from a mobile device.

In some aspects, disclosed herein is a system for coordinating access toemergency data for a plurality of emergency service providers (ESPs),the system comprising: a) a management portal comprising: i) a softwaremodule establishing one or more roles within an ESP; and ii) a softwaremodule defining customized access to emergency data from a plurality ofdata fields for the one or more roles; b) an emergency management system(EMS) comprising: i) a software module receiving an emergency datarequest from the ESP, said emergency data request associated with anelectronic device; ii) a software module identifying a recipient at theESP and determining a role established for the recipient, said rolehaving authorization to access emergency data belonging to at least onedata field from the plurality of data fields; iii) a software moduleobtaining emergency data associated with the emergency data request; andiv) a software module securely transmitting emergency data fallingwithin the at least one data field to the ESP, wherein the transmittedemergency data is formatted to be compatible with the ESP. In someembodiments, the emergency data request is associated with an emergencyalert originating from the electronic device. In some embodiments, theemergency data request comprises a unique identifier corresponding tothe electronic device. In some embodiments, the unique identifier is aphone number, Electronic Serial Number, Media Access Control (MAC)address, Temporary Mobile Station Identifier (TMSI), or InternetProtocol (IP) address of the electronic device. In some embodiments, theunique identifier is a phone number of the electronic device. In someembodiments, the emergency data request comprises credentials associatedwith the ESP. In some embodiments, the EMS verifies the credentialsassociated with the ESP before transmitting emergency data to the ESP.In some embodiments, obtaining emergency data associated with theemergency data request comprises ingesting data from at least one deviceassociated with the electronic device or a user of the electronicdevice. In some embodiments, the at least one associated device iscommunicatively linked to the electronic device. In some embodiments,the at least one associated device comprises a vehicle device, wearabledevice, or Internet of Things (IoT) device. In some embodiments, theemergency data from the at least one associated device comprises atleast one of location data, user data, and sensor data. In someembodiments, the emergency data from the at least one associated deviceincludes information on a source of the emergency data. In someembodiments, the source is a mobile application installed on theelectronic device. In some embodiments, the mobile application is asocial media application, a map application, a music or videoapplication, an emergency communications application, a chatapplication, a shopping application, or an audio or podcast application.In some embodiments, the EMS comprises a software module obtaininglocation data from an external system or device. In some embodiments,the EMS comprises a software module obtaining additional data from anexternal system or device. In some embodiments, the emergency dataassociated with the emergency data request is generated by a mobileapplication installed on the electronic device. In some embodiments, theat least one data field comprises one or more of photo, name, address,date of birth, phone number, gender, height, weight, ethnicity,languages spoken, occupation, email, notes, emergency contacts,allergies, blood type, disabilities, existing conditions, andmedications. In some embodiments, the at least one data field comprisesone or more of caller phone number, probable civic address, probablecivic address likelihood, last location update time, latitude andlongitude, uncertainty radius, confidence, and altitude. In someembodiments, the at least one data field comprises an audio or videofeed. In some embodiments, the EMS obtains data from a plurality ofnetworks and protocol types and integrates the data into one or moredatabases. In some embodiments, the emergency data request compriseslocation data associated with the electronic device. In someembodiments, the one or more roles within the ESP comprise a dispatcheror call taker role, a first responder role, a supervisor role, or anycombination thereof. In some embodiments, the plurality of data fieldscomprises data fields selected from the group consisting of useridentity data, health data, sensor data, environmental data, andlocation data. In some embodiments, the emergency alert is an emergencycall initiated by the electronic device. In some embodiments, theemergency alert comprises at least one of an emergency wireless call, anemergency landline call, a text call, and an emergency call back. Insome embodiments, the electronic device is a mobile phone, a smartphone,a tablet, a vehicle device, a medical alert device, or an Internet ofThings (IoT) device. In some embodiments, the EMS comprises a softwaremodule detecting an emergency alert sent by an electronic device. Insome embodiments, the EMS comprises a software module identifying theESP responding to the emergency alert from the plurality of ESPs. Insome embodiments, the system further comprises an enhanced data systemat the ESP for displaying the emergency data falling within the at leastone data field to a user.

In some aspects, disclosed herein is a method for coordinating access toemergency data for a plurality of emergency service providers (ESPs),the method comprising: a) establishing, at a management portal, one ormore roles within an ESP; and b) defining, at the management portal,authorization to access emergency data from a plurality of data fieldsfor the one or more roles; c) receiving, at an emergency managementsystem, receiving an emergency data request from the ESP, said emergencydata request associated with an electronic device; d) identifying, atthe emergency management system, a recipient at the ESP and determining,at the emergency management system, a role established for therecipient, said role having authorization to access emergency databelonging to at least one data field from the plurality of data fields;e) obtaining, at the emergency management system, emergency dataassociated with the emergency data request; and f) securelytransmitting, at the emergency management system, emergency data fallingwithin the at least one data field to the ESP, wherein the transmittedemergency data is formatted to be compatible with the ESP. In someembodiments, the emergency data request is associated with an emergencyalert originating from the electronic device. In some embodiments, theemergency data request comprises a unique identifier corresponding tothe electronic device. In some embodiments, the unique identifier is aphone number, Electronic Serial Number, Media Access Control (MAC)address, Temporary Mobile Station Identifier (TMSI), or InternetProtocol (IP) address of the electronic device. In some embodiments, theunique identifier is a phone number of the electronic device. In someembodiments, the emergency data request comprises credentials associatedwith the ESP. In some embodiments, the EMS verifies the credentialsassociated with the ESP before transmitting emergency data to the ESP.In some embodiments, obtaining emergency data associated with theemergency data request comprises ingesting data from at least one deviceassociated with the electronic device or a user of the electronicdevice. In some embodiments, the at least one associated device iscommunicatively linked to the electronic device. In some embodiments,the at least one associated device comprises a vehicle device, wearabledevice, or Internet of Things (IoT) device. In some embodiments, theemergency data from the at least one associated device comprises atleast one of location data, user data, and sensor data. In someembodiments, the emergency data from the at least one associated deviceincludes information on a source of the emergency data. In someembodiments, the source is a mobile application installed on theelectronic device. In some embodiments, the mobile application is asocial media application, a map application, a music or videoapplication, an emergency communications application, a chatapplication, a shopping application, or an audio or podcast application.In some embodiments, the method further comprises obtaining, by theemergency management system, location data from an external system ordevice. In some embodiments, the method further comprises obtaining, bythe emergency management system, additional data from an external systemor device. In some embodiments, the emergency data associated with theemergency data request is generated by a mobile application installed onthe electronic device. In some embodiments, the at least one data fieldcomprises one or more of photo, name, address, date of birth, phonenumber, gender, height, weight, ethnicity, languages spoken, occupation,email, notes, emergency contacts, allergies, blood type, disabilities,existing conditions, and medications. In some embodiments, the at leastone data field comprises one or more of caller phone number, probablecivic address, probable civic address likelihood, last location updatetime, latitude and longitude, uncertainty radius, confidence, andaltitude. In some embodiments, the at least one data field comprises anaudio or video feed. In some embodiments, the method further comprisesobtaining, by the emergency management system, data from a plurality ofnetworks and protocol types and integrating the data into one or moredatabases. In some embodiments, the emergency data request compriseslocation data associated with the electronic device. In someembodiments, the one or more roles within the ESP comprise a dispatcheror call taker role, a first responder role, a supervisor role, or anycombination thereof. In some embodiments, the plurality of data fieldscomprises data fields selected from the group consisting of useridentity data, health data, sensor data, environmental data, andlocation data. In some embodiments, the emergency alert is an emergencycall initiated by the electronic device. In some embodiments, theemergency alert comprises at least one of an emergency wireless call, anemergency landline call, a text call, and an emergency call back. Insome embodiments, the electronic device is a mobile phone, a smartphone,a tablet, a vehicle device, a medical alert device, or an Internet ofThings (IoT) device. In some embodiments, the method further comprisesdetecting, by the emergency management system, an emergency alert sentby an electronic device. In some embodiments, the method furthercomprises identifying, by the emergency management system, the ESPresponding to the emergency alert from the plurality of ESPs. In someembodiments, the recipient is an enhanced data system for displaying theemergency data falling within the at least one data field according toat least one of a dynamic visualization scheme and user input.

In some aspects, disclosed herein is a system for coordinating access toemergency data for a plurality of emergency service providers (ESPs),the system comprising: a) a management portal comprising: i) a softwaremodule establishing one or more roles within an ESP; and ii) a softwaremodule defining authorization to access emergency data from a pluralityof data fields for the one or more roles; b) an emergency managementsystem (EMS) comprising: i) a software module detecting an emergencyalert originating from an electronic device; ii) a software moduleidentifying the ESP from the plurality of ESPs for responding to theemergency alert; iii) a software module identifying a recipient at theESP for receiving emergency data associated with the emergency alert anddetermining a role established for the recipient, said role havingauthorization to access emergency data belonging to at least one datafield from the plurality of data fields; iv) a software module obtainingthe emergency data associated with the emergency communication; and v) asoftware module securely transmitting data falling within the at leastone data field to the ESP, wherein the transmitted emergency data isformatted to be compatible with the ESP.

In some aspects, disclosed herein is an enhanced data system comprisingat least one processor, a memory, a user interface, a display, andinstructions executable by the at least one processor to create anemergency communications application comprising: a) a software modulereceiving an emergency alert originating from an electronic device; b) asoftware module associating the emergency alert with a unique identifierof the electronic device; c) a software module sending an emergency datarequest to an emergency management system (EMS), the emergency datarequest comprising the unique identifier of the electronic device,credentials for an emergency service provider (ESP) associated with theenhanced data system, and an identifier of a role established for theenhanced data system or a user thereof; d) a software module receivingemergency data falling within at least one data field for which theenhanced data system has authorization to access according to theestablished role; and e) a software module providing an enhanced datadisplay shown through the display, said enhanced data display showingthe emergency data according to a dynamic visualization scheme. In someembodiments, the enhanced data system is a computing device at the ESP.In some embodiments, the enhanced data display is a webpage accessedthrough the emergency communications application installed on acomputing device at the ESP. In some embodiments, dynamic visualizationscheme comprises emphasizing a data field through highlighting, bolding,enlarging, underlining, moving, or coloring the data field. In someembodiments, dynamic visualization scheme is applied in response to userinput. In some embodiments, the unique identifier is a phone number,Electronic Serial Number, Media Access Control (MAC) address, TemporaryMobile Station Identifier (TMSI), or Internet Protocol (IP) address ofthe electronic device. In some embodiments, the unique identifier is aphone number of the electronic device. In some embodiments, theemergency data is sourced from at least one device associated with theelectronic device or a user of the electronic device. In someembodiments, the at least one associated device is communicativelylinked to the electronic device. In some embodiments, the at least oneassociated device comprises a vehicle device, wearable device, orInternet of Things (IoT) device. In some embodiments, the emergency datafrom the at least one associated device comprises at least one oflocation data, user data, and sensor data. In some embodiments, theemergency data from the at least one associated device includesinformation on a source of the emergency data. In some embodiments, thesource is a mobile application installed on the electronic device. Insome embodiments, the mobile application is a social media application,a map application, a music or video application, an emergencycommunications application, a chat application, a shopping application,or an audio or podcast application. In some embodiments, the emergencydata associated with the emergency data request is generated by a mobileapplication installed on the electronic device. In some embodiments, theat least one data field comprises one or more of photo, name, address,date of birth, phone number, gender, height, weight, ethnicity,languages spoken, occupation, email, notes, emergency contacts,allergies, blood type, disabilities, existing conditions, andmedications. In some embodiments, the at least one data field comprisesone or more of caller phone number, probable civic address, probablecivic address likelihood, last location update time, latitude andlongitude, uncertainty radius, confidence, and altitude. In someembodiments, the at least one data field comprises an audio or videofeed. In some embodiments, the emergency data request comprises locationdata associated with the electronic device. In some embodiments, therole is a dispatcher or call taker role, a first responder role, asupervisor role, or any combination thereof. In some embodiments, the atleast one category comprises at least one of user identity data, healthdata, sensor data, environmental data, and location data. In someembodiments, the emergency alert comprises at least one of an emergencywireless call, an emergency landline call, a text call, and an emergencycall back. In some embodiments, the electronic device is a mobile phone,a smartphone, a tablet, a vehicle device, a medical alert device, or anInternet of Things (IoT) device.

In some aspects, disclosed herein is non-transitory computer readablestorage media encoded with a computer program including instructionsexecutable by at least one processor for creating an emergencycommunications application comprising: a) a software module receiving anemergency alert originating from an electronic device; b) a softwaremodule associating the emergency alert with a unique identifier of theelectronic device; c) a software module sending an emergency datarequest to an emergency management system (EMS), the emergency datarequest comprising the unique identifier of the electronic device,credentials for an emergency service provider (ESP) associated with theenhanced data system, and an identifier of a role established for theenhanced data system or a user thereof d) a software module receivingemergency data falling within at least one data field for which theenhanced data system has authorization to access according to theestablished role; and e) a software module providing an enhanced datadisplay shown through the display, said enhanced data display showingthe emergency data according to a dynamic visualization scheme. In someembodiments, the enhanced data system is a computing device at the ESP.In some embodiments, the enhanced data display is a webpage accessedthrough the emergency communications application installed on acomputing device at the ESP. In some embodiments, dynamic visualizationscheme comprises emphasizing a data field through highlighting, bolding,enlarging, underlining, moving, or coloring the data field. In someembodiments, dynamic visualization scheme is applied in response to userinput. In some embodiments, the unique identifier is a phone number,Electronic Serial Number, Media Access Control (MAC) address, TemporaryMobile Station Identifier (TMSI), or Internet Protocol (IP) address ofthe electronic device. In some embodiments, the unique identifier is aphone number of the electronic device. In some embodiments, theemergency data is sourced from at least one device associated with theelectronic device or a user of the electronic device. In someembodiments, the at least one associated device is communicativelylinked to the electronic device. In some embodiments, the at least oneassociated device comprises a vehicle device, wearable device, orInternet of Things (IoT) device. In some embodiments, the emergency datafrom the at least one associated device comprises at least one oflocation data, user data, and sensor data. In some embodiments, theemergency data from the at least one associated device includesinformation on a source of the emergency data. In some embodiments, thesource is a mobile application installed on the electronic device. Insome embodiments, the mobile application is a social media application,a map application, a music or video application, an emergencycommunications application, a chat application, a shopping application,or an audio or podcast application. In some embodiments, the emergencydata associated with the emergency data request is generated by a mobileapplication installed on the electronic device. In some embodiments, theat least one data field comprises one or more of photo, name, address,date of birth, phone number, gender, height, weight, ethnicity,languages spoken, occupation, email, notes, emergency contacts,allergies, blood type, disabilities, existing conditions, andmedications. In some embodiments, the at least one data field comprisesone or more of caller phone number, probable civic address, probablecivic address likelihood, last location update time, latitude andlongitude, uncertainty radius, confidence, and altitude. In someembodiments, the at least one data field comprises an audio or videofeed. In some embodiments, the emergency data request comprises locationdata associated with the electronic device. In some embodiments, therole is a dispatcher or call taker role, a first responder role, asupervisor role, or any combination thereof. In some embodiments, the atleast one data field comprises at least one of user identity data,health data, sensor data, environmental data, and location data. In someembodiments, the emergency alert comprises at least one of an emergencywireless call, an emergency landline call, a text call, and an emergencycall back. In some embodiments, the electronic device is a mobile phone,a smartphone, a tablet, a vehicle device, a medical alert device, or anInternet of Things (IoT) device.

In some aspects, disclosed herein is a computer-implemented method formanaging emergency communications, comprising: a) receiving an emergencyalert originating from an electronic device; b) associating theemergency alert with a unique identifier of the electronic device; c) asoftware module sending an emergency data request to an emergencymanagement system (EMS), the emergency data request comprising theunique identifier of the electronic device, credentials for an emergencyservice provider (ESP) associated with the enhanced data system, and anidentifier of a role established for the enhanced data system or a userthereof; d) receiving emergency data falling within at least one datafield for which the enhanced data system has authorization to accessaccording to the established role; and e) providing an enhanced datadisplay shown through the display, said enhanced data display showingthe emergency data according to a dynamic visualization scheme. In someembodiments, the enhanced data system is a computing device at the ESP.In some embodiments, the enhanced data display is a webpage accessedthrough the emergency communications application installed on acomputing device at the ESP. In some embodiments, dynamic visualizationscheme comprises emphasizing a data field through highlighting, bolding,enlarging, underlining, moving, or coloring the data field. In someembodiments, dynamic visualization scheme is applied in response to userinput. In some embodiments, the unique identifier is a phone number,Electronic Serial Number, Media Access Control (MAC) address, TemporaryMobile Station Identifier (TMSI), or Internet Protocol (IP) address ofthe electronic device. In some embodiments, the unique identifier is aphone number of the electronic device. In some embodiments, theemergency data is sourced from at least one device associated with theelectronic device or a user of the electronic device. In someembodiments, the at least one associated device is communicativelylinked to the electronic device. In some embodiments, the at least oneassociated device comprises a vehicle device, wearable device, orInternet of Things (IoT) device. In some embodiments, the emergency datafrom the at least one associated device comprises at least one oflocation data, user data, and sensor data. In some embodiments, theemergency data from the at least one associated device includesinformation on a source of the data. In some embodiments, the source isa mobile application installed on the electronic device. In someembodiments, the mobile application is a social media application, a mapapplication, a music or video application, an emergency communicationsapplication, a chat application, a shopping application, or an audio orpodcast application. In some embodiments, the emergency data associatedwith the emergency data request is generated by a mobile applicationinstalled on the electronic device. In some embodiments, the at leastone data field comprises one or more of photo, name, address, date ofbirth, phone number, gender, height, weight, ethnicity, languagesspoken, occupation, email, notes, emergency contacts, allergies, bloodtype, disabilities, existing conditions, and medications. In someembodiments, the at least one data field comprises one or more of callerphone number, probable civic address, probable civic address likelihood,last location update time, latitude and longitude, uncertainty radius,confidence, and altitude. In some embodiments, the at least one datafield comprises an audio or video feed. In some embodiments, theemergency data request comprises location data associated with theelectronic device. In some embodiments, the role is a dispatcher or calltaker role, a first responder role, a supervisor role, or anycombination thereof. In some embodiments, the at least one data fieldcomprises at least one of user identity data, health data, sensor data,environmental data, and location data. In some embodiments, theemergency alert comprises at least one of an emergency wireless call, anemergency landline call, a text call, and an emergency call back. Insome embodiments, the electronic device is a mobile phone, a smartphone,a tablet, a vehicle device, a medical alert device, or an Internet ofThings (IoT) device.

In another aspect, disclosed herein is a system for managing access toemergency data for emergency service providers, the system comprising:(a) a management portal implemented as one or more software modules on acomputing system comprising a processor and a non-transitory computerreadable storage medium and configured to: (i) establish a first rolethat can be selected for one or more users within an ESP; and (ii)define a first set of emergency data fields that is accessible by an ESPuser associated with the first role; (b) an emergency responseapplication implemented as one or more software modules on a computingsystem comprising a processor, a display, and a non-transitory computerreadable storage medium and configured to: (i) log the ESP userassociated with the first role into the emergency response application;(ii) generate an emergency data request comprising an identifierassociated with an emergency alert; and (iii) transmit the emergencydata request to an emergency management system; and (c) the emergencymanagement system, implemented as one or more software modules on acloud computing system comprising a processor and a non-transitorycomputer readable storage medium and configured to: (i) receive theemergency data request from the emergency response application; (ii)gather, using the identifier, emergency data corresponding to the firstset of emergency data fields and associated with the emergency alert;and (iii) securely transmit the emergency data associated with theemergency alert to the emergency response application for display on thecomputing system in (b). In some embodiments, the management portal isfurther configured to: (a) establish a second role that can be selectedfor one or more users within the ESP; and (b) define a second set ofemergency data fields that is accessible by any ESP user associated withthe second role, wherein the first set of emergency data fields and thesecond set of emergency data fields comprise different sets of emergencydata fields. In some embodiments, the second set of emergency datafields is defined from a plurality of emergency data fields. In someembodiments, the first set of emergency data fields is defined from aplurality of emergency data fields. In some embodiments, the first setof emergency data fields is defined using one or more emergency datacategories, wherein each emergency data category comprises two or moreemergency data fields. In some embodiments: (a) the emergency datarequest comprises one or more tags indicative of the first set ofemergency data categories; and (b) the emergency management system isfurther configured to determine the first set of emergency datacategories using the one or more tags. In some embodiments, theemergency response application is further configured to: (a) detect theemergency alert when the emergency alert is received by the ESP; and (b)autonomously generate the emergency data request in response todetecting the emergency alert. In some embodiments, the emergencyresponse application is further configured to generate the emergencydata request in response to user input at the emergency responseapplication. In some embodiments, the management portal furthercomprises a graphical user interface shown on a display of the computingsystem on which the management portal is implemented, and wherein themanagement portal is further configured to: (a) display the plurality ofemergency data fields or a plurality of emergency data categories on thedisplay; and (b) receive choice of the set of emergency data fields orone or more emergency data categories comprising the set of emergencydata fields from the plurality of emergency data fields or the pluralityof emergency data categories by an administrator of the ESP through thegraphical user interface. In some embodiments: (a) the emergency datarequest comprises one or more tags indicative of the first set ofemergency data fields that is accessible to the ESP user associated withthe first role; and (b) the emergency management system is furtherconfigured to determine the first set of emergency data fields that isaccessible to the ESP user associated with the first role using the oneor more tags. In some embodiments: (a) the emergency data requestcomprises an identifier of the first role; and (b) the emergencymanagement system is further configured to determine the set ofemergency data fields that is accessible to the ESP user associated withthe first role by querying the management portal using the identifier ofthe first role. In some embodiments, the emergency response applicationis further configured to detect the emergency alert, wherein theemergency alert is generated by an electronic device and wherein theidentifier associated with the emergency alert is a phone numberassociated with the electronic device. In some embodiments, theemergency alert is an emergency all made to the ESP by the electronicdevice. In some embodiments, the first set of emergency data fields thatis accessible to the ESP user associated with the first role compriseslocation data, and wherein the emergency data associated with theemergency alert comprises a location. In some embodiments, the emergencymanagement system is further configured to: (a) obtain a locationassociated with the emergency alert; (b) access a geofence associatedwith the ESP; and (c) determine if the location falls within thegeofence associated with the ESP. In some embodiments, the emergencymanagement system is further configured to: (a) obtain a locationassociated with the emergency alert; (b) access a geofence associatedwith the ESP; (c) determine if the location falls within the geofenceassociated with the ESP; and (d) gather the emergency data correspondingto the first set of emergency data fields and associated with theemergency alert only if the location is determined to fall within thegeofence associated with the ESP. In some embodiments, the emergencymanagement system further comprises a software module configured toingest data from at least one electronic device associated with theemergency alert.

In another aspect, disclosed herein is a system for managing access toemergency data for emergency service providers, the system comprising:(a) a management portal implemented as one or more software modules on acomputing system comprising a processor and a non-transitory computerreadable storage medium and configured to: (i) establish a first rolethat can be selected for one or more users within an ESP; and (ii)define a first set of emergency data fields that is accessible by an ESPuser associated with the first role; and (b) an emergency responseapplication implemented as one or more software modules on a computingsystem comprising a processor, a display, and a non-transitory computerreadable storage medium and configured to: (i) log the ESP userassociated with the first role into the emergency response application;(ii) generate an emergency data request comprising an identifierassociated with an emergency alert; (iii) transmit the emergency datarequest to an emergency management system; (iv) receive emergency datacorresponding to the first set of emergency data fields and associatedwith the emergency alert; and (v) display the emergency data on thecomputing system. In some embodiments, the management portal is furtherconfigured to: (a) establish a second role that can be selected for oneor more users within the ESP; and (b) define a second set of emergencydata fields that is accessible by any ESP user associated with thesecond role, wherein the first set of emergency data fields and thesecond set of emergency data fields comprise different sets of emergencydata fields. In some embodiments, the second set of emergency datafields is defined from a plurality of emergency data fields. In someembodiments, the first set of emergency data fields is defined from aplurality of emergency data fields. In some embodiments, the first setof emergency data fields is defined using one or more emergency datacategories, wherein each emergency data category comprises two or moreemergency data fields. In some embodiments: (a) the emergency datarequest comprises one or more tags indicative of the first set ofemergency data categories; and (b) the emergency management system isfurther configured to determine the first set of emergency datacategories using the one or more tags. In some embodiments, theemergency response application is further configured to: (a) detect theemergency alert when the emergency alert is received by the ESP; and (b)autonomously generate the emergency data request in response todetecting the emergency alert. In some embodiments, the emergencyresponse application is further configured to generate the emergencydata request in response to user input at the emergency responseapplication. In some embodiments, the management portal furthercomprises a graphical user interface shown on a display of the computingsystem on which the management portal is implemented, and wherein themanagement portal is further configured to: (a) display the plurality ofemergency data fields or a plurality of emergency data categories on thedisplay; and (b) receive choice of the set of emergency data fields orone or more emergency data categories comprising the set of emergencydata fields from the plurality of emergency data fields or the pluralityof emergency data categories by an administrator of the ESP through thegraphical user interface. In some embodiments: (a) the emergency datarequest comprises one or more tags indicative of the first set ofemergency data fields that is accessible to the ESP user associated withthe first role; and (b) the emergency management system is furtherconfigured to determine the first set of emergency data fields that isaccessible to the ESP user associated with the first role using the oneor more tags. In some embodiments: (a) the emergency data requestcomprises an identifier of the first role; and (b) the emergencymanagement system is further configured to determine the set ofemergency data fields that is accessible to the ESP user associated withthe first role by querying the management portal using the identifier ofthe first role. In some embodiments, the emergency response applicationis further configured to detect the emergency alert, wherein theemergency alert is generated by an electronic device and wherein theidentifier associated with the emergency alert is a phone numberassociated with the electronic device. In some embodiments, theemergency alert is an emergency all made to the ESP by the electronicdevice. In some embodiments, the first set of emergency data fields thatis accessible to the ESP user associated with the first role compriseslocation data, and wherein the emergency data associated with theemergency alert comprises a location. In some embodiments, the emergencymanagement system is further configured to: (a) obtain a locationassociated with the emergency alert; (b) access a geofence associatedwith the ESP; and (c) determine if the location falls within thegeofence associated with the ESP. In some embodiments, the emergencymanagement system is further configured to: (a) obtain a locationassociated with the emergency alert; (b) access a geofence associatedwith the ESP; (c) determine if the location falls within the geofenceassociated with the ESP; and (d) gather the emergency data correspondingto the first set of emergency data fields and associated with theemergency alert only if the location is determined to fall within thegeofence associated with the ESP. In some embodiments, the emergencymanagement system further comprises a software module configured toingest data from at least one electronic device associated with theemergency alert. In another aspect, disclosed herein is a non-transitorycomputer readable storage media encoded with a computer programincluding instructions executable by at least one processor forperforming any of the steps implemented on the systems disclosed herein.In another aspect, disclosed herein is a method for managing access toemergency data for emergency service providers, the method comprisingany of the steps implemented on the systems disclosed herein.

In another aspect, disclosed herein is a system for managing access toemergency data for emergency service providers, the system comprising:(a) a management portal implemented as one or more software modules on acomputing system comprising a processor and a non-transitory computerreadable storage medium and configured to: (i) establish a first rolethat can be selected for one or more users within an ESP; and (ii)define a first set of emergency data fields that is accessible by an ESPuser associated with the first role; and (b) the emergency managementsystem, implemented as one or more software modules on a cloud computingsystem comprising a processor and a non-transitory computer readablestorage medium and configured to: (i) receive an emergency data requestcomprising an identifier associated with an emergency alert from anaccount of an ESP user associated with the first role at the ESP; (ii)gather, using the identifier associated with the emergency alert,emergency data corresponding to the first set of emergency data fieldsand associated with the emergency alert; and (iii) securely transmit theemergency data to the ESP for display on a computing system. In someembodiments, the management portal is further configured to: (a)establish a second role that can be selected for one or more userswithin the ESP; and (b) define a second set of emergency data fieldsthat is accessible by any ESP user associated with the second role,wherein the first set of emergency data fields and the second set ofemergency data fields comprise different sets of emergency data fields.In some embodiments, the second set of emergency data fields is definedfrom a plurality of emergency data fields. In some embodiments, thefirst set of emergency data fields is defined from a plurality ofemergency data fields. In some embodiments, the first set of emergencydata fields is defined using one or more emergency data categories,wherein each emergency data category comprises two or more emergencydata fields. In some embodiments: (a) the emergency data requestcomprises one or more tags indicative of the first set of emergency datacategories; and (b) the emergency management system is furtherconfigured to determine the first set of emergency data categories usingthe one or more tags. In some embodiments, the emergency responseapplication is further configured to: (a) detect the emergency alertwhen the emergency alert is received by the ESP; and (b) autonomouslygenerate the emergency data request in response to detecting theemergency alert. In some embodiments, the emergency response applicationis further configured to generate the emergency data request in responseto user input at the emergency response application. In someembodiments, the management portal further comprises a graphical userinterface shown on a display of the computing system on which themanagement portal is implemented, and wherein the management portal isfurther configured to: (a) display the plurality of emergency datafields or a plurality of emergency data categories on the display; and(b) receive choice of the set of emergency data fields or one or moreemergency data categories comprising the set of emergency data fieldsfrom the plurality of emergency data fields or the plurality ofemergency data categories by an administrator of the ESP through thegraphical user interface. In some embodiments: (a) the emergency datarequest comprises one or more tags indicative of the first set ofemergency data fields that is accessible to the ESP user associated withthe first role; and (b) the emergency management system is furtherconfigured to determine the first set of emergency data fields that isaccessible to the ESP user associated with the first role using the oneor more tags. In some embodiments: (a) the emergency data requestcomprises an identifier of the first role; and (b) the emergencymanagement system is further configured to determine the set ofemergency data fields that is accessible to the ESP user associated withthe first role by querying the management portal using the identifier ofthe first role. In some embodiments, the emergency response applicationis further configured to detect the emergency alert, wherein theemergency alert is generated by an electronic device and wherein theidentifier associated with the emergency alert is a phone numberassociated with the electronic device. In some embodiments, theemergency alert is an emergency all made to the ESP by the electronicdevice. In some embodiments, the first set of emergency data fields thatis accessible to the ESP user associated with the first role compriseslocation data, and wherein the emergency data associated with theemergency alert comprises a location. In some embodiments, the emergencymanagement system is further configured to: (a) obtain a locationassociated with the emergency alert; (b) access a geofence associatedwith the ESP; and (c) determine if the location falls within thegeofence associated with the ESP. In some embodiments, the emergencymanagement system is further configured to: (a) obtain a locationassociated with the emergency alert; (b) access a geofence associatedwith the ESP; (c) determine if the location falls within the geofenceassociated with the ESP; and (d) gather the emergency data correspondingto the first set of emergency data fields and associated with theemergency alert only if the location is determined to fall within thegeofence associated with the ESP. In some embodiments, the emergencymanagement system further comprises a software module configured toingest data from at least one electronic device associated with theemergency alert. In another aspect, disclosed herein is a non-transitorycomputer readable storage media encoded with a computer programincluding instructions executable by at least one processor forperforming any of the steps implemented on the systems disclosed herein.In another aspect, disclosed herein is a method for managing access toemergency data for emergency service providers, the method comprisingany of the steps implemented on the systems disclosed herein.

In another aspect, disclosed herein is a system for managing access toemergency data for emergency service providers, the system comprising:(a) a management portal implemented as one or more software modules on acomputing system comprising a processor and a non-transitory computerreadable storage medium and configured to: (i) establish a first rolethat can be selected for one or more users within an ESP; and (ii)define a first set of emergency data fields that is accessible by an ESPuser associated with the first role; (b) an emergency responseapplication implemented as one or more software modules on a computingsystem comprising a processor, a display, and a non-transitory computerreadable storage medium and configured to: (i) log the ESP userassociated with the first role into the emergency response application;(ii) generate an emergency data request comprising an identifierassociated with an emergency alert; and (iii) transmit the emergencydata request to an emergency management system; and (c) the emergencymanagement system, implemented as one or more software modules on acloud computing system comprising a processor and a non-transitorycomputer readable storage medium and configured to: (i) receive theemergency alert, wherein the emergency alert comprises a location; (ii)access a geofence associated with the ESP; (iii) determine if thelocation falls within the geofence associated with the ESP; (iv) receivethe emergency data request from the emergency response application; (v)based upon a determination that the location falls within the geofenceassociated with the ESP, gather, using the identifier associated withthe emergency alert, emergency data corresponding to the first set ofemergency data fields and associated with the emergency alert; and (vi)securely transmit the emergency data to the emergency responseapplication for display at the computing system. In some embodiments,the management portal is further configured to: (a) establish a secondrole that can be selected for one or more users within the ESP; and (b)define a second set of emergency data fields that is accessible by anyESP user associated with the second role, wherein the first set ofemergency data fields and the second set of emergency data fieldscomprise different sets of emergency data fields. In some embodiments,the second set of emergency data fields is defined from a plurality ofemergency data fields. In some embodiments, the first set of emergencydata fields is defined from a plurality of emergency data fields. Insome embodiments, the first set of emergency data fields is definedusing one or more emergency data categories, wherein each emergency datacategory comprises two or more emergency data fields. In someembodiments: (a) the emergency data request comprises one or more tagsindicative of the first set of emergency data categories; and (b) theemergency management system is further configured to determine the firstset of emergency data categories using the one or more tags. In someembodiments, the emergency response application is further configuredto: (a) detect the emergency alert when the emergency alert is receivedby the ESP; and (b) autonomously generate the emergency data request inresponse to detecting the emergency alert. In some embodiments, theemergency response application is further configured to generate theemergency data request in response to user input at the emergencyresponse application. In some embodiments, the management portal furthercomprises a graphical user interface shown on a display of the computingsystem on which the management portal is implemented, and wherein themanagement portal is further configured to: (a) display the plurality ofemergency data fields or a plurality of emergency data categories on thedisplay; and (b) receive choice of the set of emergency data fields orone or more emergency data categories comprising the set of emergencydata fields from the plurality of emergency data fields or the pluralityof emergency data categories by an administrator of the ESP through thegraphical user interface. In some embodiments: (a) the emergency datarequest comprises one or more tags indicative of the first set ofemergency data fields that is accessible to the ESP user associated withthe first role; and (b) the emergency management system is furtherconfigured to determine the first set of emergency data fields that isaccessible to the ESP user associated with the first role using the oneor more tags. In some embodiments: (a) the emergency data requestcomprises an identifier of the first role; and (b) the emergencymanagement system is further configured to determine the set ofemergency data fields that is accessible to the ESP user associated withthe first role by querying the management portal using the identifier ofthe first role. In some embodiments, the emergency response applicationis further configured to detect the emergency alert, wherein theemergency alert is generated by an electronic device and wherein theidentifier associated with the emergency alert is a phone numberassociated with the electronic device. In some embodiments, theemergency alert is an emergency all made to the ESP by the electronicdevice. In some embodiments, the first set of emergency data fields thatis accessible to the ESP user associated with the first role compriseslocation data, and wherein the emergency data associated with theemergency alert comprises a location. In some embodiments, the emergencymanagement system is further configured to: (a) obtain a locationassociated with the emergency alert; (b) access a geofence associatedwith the ESP; and (c) determine if the location falls within thegeofence associated with the ESP. In some embodiments, the emergencymanagement system is further configured to: (a) obtain a locationassociated with the emergency alert; (b) access a geofence associatedwith the ESP; (c) determine if the location falls within the geofenceassociated with the ESP; and (d) gather the emergency data correspondingto the first set of emergency data fields and associated with theemergency alert only if the location is determined to fall within thegeofence associated with the ESP. In some embodiments, the emergencymanagement system further comprises a software module configured toingest data from at least one electronic device associated with theemergency alert. In another aspect, disclosed herein is a non-transitorycomputer readable storage media encoded with a computer programincluding instructions executable by at least one processor forperforming any of the steps implemented on the systems disclosed herein.In another aspect, disclosed herein is a method for managing access toemergency data for emergency service providers, the method comprisingany of the steps implemented on the systems disclosed herein.

BRIEF DESCRIPTION OF THE DRAWINGS

The novel features of the present invention of the instant applicationare set forth with particularity in the appended claims. A betterunderstanding of the features and advantages of the present inventionwill be obtained by reference to the following detailed description thatsets forth illustrative embodiments, in which the principles of thepresent invention are utilized, and the accompanying drawings of which:

FIG. 1A depicts diagrams of an electronic device and an emergencymanagement system (EMS) in accordance with one embodiment;

FIG. 1B depicts diagrams of an emergency service provider (ESP) systemand ESP software in accordance with one embodiment;

FIG. 2 depicts a diagram of a clearinghouse for emergency data inaccordance with one embodiment;

FIG. 3 depicts a diagram of an emergency service provider (ESP)integration system in accordance with one embodiment;

FIG. 4A depicts a diagram of an ESP administrator, an EMS, and an ESPpersonnel in accordance with one embodiment;

FIG. 4B depicts a diagram of an ESP administrator, an EMS, and an ESPpersonnel in accordance with one embodiment;

FIG. 5A, FIG. 5B, FIG. 5C, FIG. 5D, FIG. 5E, FIG. 5F, and FIG. 5Gillustrate embodiments of a management portal in accordance with oneembodiment;

FIG. 6 depicts a diagram of an emergency data management process inaccordance with one embodiment;

FIG. 7 depicts n flow diagram of an emergency data management process inaccordance with one embodiment;

FIG. 8A depicts a flow diagram of an authentication process inaccordance with one embodiment;

FIG. 8B depicts a second flow diagram of an authentication process inaccordance with one embodiment;

FIG. 8C depicts a third flow diagram of an authentication process inaccordance with one embodiment;

FIG. 9 depicts an flow diagram of an emergency data retrieval process inaccordance with one embodiment;

FIG. 10A illustrates an embodiment of an enhanced data displaydisplaying location coordinates in accordance with one embodiment;

FIG. 10B illustrates an embodiment of an enhanced data displaydisplaying demographic data in accordance with one embodiment;

FIG. 11A illustrates an embodiment of an enhanced data display inaccordance with one embodiment;

FIG. 11B illustrates an embodiment of an enhanced data displayemphasizing demographic data in accordance with one embodiment; and

FIG. 11C illustrates an embodiment of an enhanced data displayemphasizing contact information in accordance with one embodiment;

FIG. 12 illustrates an embodiment of an emergency response applicationin accordance with one embodiment;

FIG. 13A and FIG. 13B depict diagrams of a geofence system applied to aclearinghouse for emergency data in accordance with one embodiment; and

FIG. 14 depicts a diagram of an emergency response application system inaccordance with one embodiment.

DETAILED DESCRIPTION

Disclosed herein are systems, devices, media, and methods for providingenhanced emergency communications. Embodiments of the present disclosuretake advantage of technological advancements that have allowed formobile communication devices to generate accurate locations byincorporating multiple technologies embedded in the devices, such asGPS, Wi-Fi, and Bluetooth, to create device-based hybrid locations.Device-based hybrid locations are locations calculated on an electronicor communication device, as opposed to locations calculated using anetwork (e.g., a carrier network). Device-based hybrid locations can begenerated using GPS, network-based technologies, Wi-Fi access points,Bluetooth beacons, barometric pressure sensors, dead reckoning usingaccelerometers and gyrometers, and a variety of crowdsourced andproprietary databases that device operating systems providers arerunning to enhance location technology. These device-based hybridlocations can be quickly generated during emergency calls.

Furthermore, mobile communication devices (e.g., mobile phones,wearables, IoT devices, smart home, vehicle computers, etc.) are capableof generating or storing additional information that may be useful inresponding to emergency situations, such as health data or medicalhistories. For example, during an emergency, a modern mobilecommunication device may have access to an implicated person's bloodtype, preexisting medical conditions, or even the implicated person'scurrent heartrate. In some embodiments, the mobile communication devicehas access to data from sensors (e.g., health or environmental sensors).For example, a video feed of the emergency via a connected surveillancecamera provides valuable situational awareness regarding the emergency.

In another aspect, disclosed herein is a system for managing access toemergency data for emergency service providers, the system comprising:(a) a management portal implemented as one or more software modules on acomputing system comprising a processor and a non-transitory computerreadable storage medium and configured to: (i) establish a first rolethat can be selected for one or more users within an ESP; and (ii)define a first set of emergency data fields that is accessible by an ESPuser associated with the first role; and (b) an emergency responseapplication implemented as one or more software modules on a computingsystem comprising a processor, a display, and a non-transitory computerreadable storage medium and configured to: (i) log the ESP userassociated with the first role into the emergency response application;(ii) generate an emergency data request comprising an identifierassociated with an emergency alert; (iii) transmit the emergency datarequest to an emergency management system; (iv) receive emergency datacorresponding to the first set of emergency data fields and associatedwith the emergency alert; and (v) display the emergency data on thecomputing system. In another aspect, disclosed herein is anon-transitory computer readable storage media encoded with a computerprogram including instructions executable by at least one processor forperforming any of the steps implemented on the systems disclosed herein.In another aspect, disclosed herein is a method for managing access toemergency data for emergency service providers, the method comprisingany of the steps implemented on the systems disclosed herein.

In another aspect, disclosed herein is a system for managing access toemergency data for emergency service providers, the system comprising:(a) a management portal implemented as one or more software modules on acomputing system comprising a processor and a non-transitory computerreadable storage medium and configured to: (i) establish a first rolethat can be selected for one or more users within an ESP; and (ii)define a first set of emergency data fields that is accessible by an ESPuser associated with the first role; and (b) the emergency managementsystem, implemented as one or more software modules on a cloud computingsystem comprising a processor and a non-transitory computer readablestorage medium and configured to: (i) receive an emergency data requestcomprising an identifier associated with an emergency alert from anaccount of an ESP user associated with the first role at the ESP; (ii)gather, using the identifier associated with the emergency alert,emergency data corresponding to the first set of emergency data fieldsand associated with the emergency alert; and (iii) securely transmit theemergency data to the ESP for display on a computing system. In anotheraspect, disclosed herein is a non-transitory computer readable storagemedia encoded with a computer program including instructions executableby at least one processor for performing any of the steps implemented onthe systems disclosed herein. In another aspect, disclosed herein is amethod for managing access to emergency data for emergency serviceproviders, the method comprising any of the steps implemented on thesystems disclosed herein.

In another aspect, disclosed herein is a system for managing access toemergency data for emergency service providers, the system comprising:(a) a management portal implemented as one or more software modules on acomputing system comprising a processor and a non-transitory computerreadable storage medium and configured to: (i) establish a first rolethat can be selected for one or more users within an ESP; and (ii)define a first set of emergency data fields that is accessible by an ESPuser associated with the first role; (b) an emergency responseapplication implemented as one or more software modules on a computingsystem comprising a processor, a display, and a non-transitory computerreadable storage medium and configured to: (i) log the ESP userassociated with the first role into the emergency response application;(ii) generate an emergency data request comprising an identifierassociated with an emergency alert; and (iii) transmit the emergencydata request to an emergency management system; and (c) the emergencymanagement system, implemented as one or more software modules on acloud computing system comprising a processor and a non-transitorycomputer readable storage medium and configured to: (i) receive theemergency alert, wherein the emergency alert comprises a location; (ii)access a geofence associated with the ESP; (iii) determine if thelocation falls within the geofence associated with the ESP; (iv) receivethe emergency data request from the emergency response application; (v)based upon a determination that the location falls within the geofenceassociated with the ESP, gather, using the identifier associated withthe emergency alert, emergency data corresponding to the first set ofemergency data fields and associated with the emergency alert; and (vi)securely transmit the emergency data to the emergency responseapplication for display at the computing system. In another aspect,disclosed herein is a non-transitory computer readable storage mediaencoded with a computer program including instructions executable by atleast one processor for performing any of the steps implemented on thesystems disclosed herein. In another aspect, disclosed herein is amethod for managing access to emergency data for emergency serviceproviders, the method comprising any of the steps implemented on thesystems disclosed herein.

Certain Terminologies

Unless otherwise defined, all technical terms used herein have the samemeaning as commonly understood by one of ordinary skill in the art towhich this invention belongs. As used in this specification and theappended claims, the singular forms “a,” “an,” and “the” include pluralreferences unless the context clearly dictates otherwise. Any referenceto “or” herein is intended to encompass “and/or” unless otherwisestated.

As used herein, an “electronic device” is a digital processing devicedesigned with one or more functionalities such as, for example, acommunication device. A “triggering device” refers to an electronicdevice with a communication component, which will allow it to send andreceive information over a wireless channel, a wired channel, or anycombination thereof (e.g., sending/receiving information over theInternet). Examples of triggering devices include a mobile phone (e.g.,a smartphone), a laptop, a desktop, a tablet, a radio (e.g., a two-wayradio), and a vehicular communication system. In some embodiments, atriggering device includes a car security system (e.g., OnStar®), a homesecurity system, or a home control system (e.g., a networked controlsystem for providing network controlled and/or smart temperature controlsuch as a Wi-Fi smart thermostat, lighting, entertainment, and/or doorcontrol, such as Nest®). In some embodiments, a triggering device is anInternet of Things (IoT) device. In some embodiments, the triggeringdevice is a sensor for sensing environmental or health indicators. Insome embodiments, the sensor includes a sensing component and acommunication component. In some embodiments, the triggering device is asensor in a sensor network or a device that controls a sensor network.In some embodiments, the triggering device is a physical panic button orsoftware “panic” button.

In some embodiments, a triggering device is a wearable device (e.g., acommunication device worn by a user, such as an Apple Watch). In someembodiments, a triggering device (e.g., a wearable device) comprises oneor more sensors. The one or more sensors optionally include, but are notlimited to: a gyroscope, an accelerometer, a thermometer, a heart ratesensor, a barometer, or a hematology analyzer. As used herein, a “mobilewireless device” refers to a device that is portable and communicateswirelessly. In some embodiments, a user wears or carries the mobilewireless device on the user's person or in the user's vehicle. Examplesof mobile wireless devices include mobile or cellular phones, wearabledevices (e.g., smart watch, fitness tracker, wearable sensor, smartglasses, etc.).

As used herein, an “associated device” refers to a communication devicethat is associated with an electronic device. For example, a user isusing several communication devices such as a mobile phone, a wearable,a home security system, a car computer. The user has registered thesedevices with his or her account(s) and linked these devices with a username, user number(s), email address(es), home or other physicaladdress(es). In some embodiments, associated devices includecommunication devices of at least one additional user who is associatedwith user, e.g., a husband and wife, a father and son, a patient anddoctor, friends, work colleagues, etc. In some cases, the user has addedthe second user as an emergency contact, a primary contact, a secondarycontact, or a member of a group (e.g., part of the same club,organization, or workplace). In some cases, user has agreed to sharelocation and other data with the second user. In some embodiments, thesecond user is someone who is frequently contacted by the user and thecommunication device identifies the second user from the “Recentlycalled” or “Frequently called” list. In some embodiments, the associateddevices are devices that are proximal or near-by to the triggeringdevice such as obtained through a Wi-Fi scan. In some embodiments, anassociated device is proximal to the triggering device when the locationof the associated device is within 1, 5, 10, 15, 20, 25, 30, 35, 40, 45,50, 60, 70, 80, 90, 100, 200, 300, 400, or 500 meters of the location ofthe triggering device, including increments therein.

As used herein, the “list of associated devices” refers to a list ofcommunication devices that are associated with the user or thetriggering device (e.g., a second resident in a smart home). Theassociated devices are optionally listed by user name, phone number,email address, physical address, coordinates etc. The device entry inthe list optionally comprises phone number, email address, physicaladdress, coordinates, BSSID, SSID or MAC address. The list is optionallyuser-defined or generated by the device or the EMS. An entry in the listof associated devices may also be referred to as an account associatedwith the user.

As used herein, an “emergency alert” refers to a communication relatingto an emergency or non-emergency situation. In some embodiments, anemergency alert is an emergency request for assistance (e.g., therequest is associated with an emergency situation). In some embodiments,an emergency alert comprises an emergency indication. In furtherembodiments, an emergency indication is selected from one or more of thegroup consisting of traffic accident, police emergency, medicalemergency, and fire emergency. In some embodiments, an emergency alertis associated with a non-emergency situation (e.g., request for a towtruck after car breaks down). In some embodiments, an emergency alert isassociated with a device sending the alert. In other embodiments, anemergency alert is associated with a device not sending the alert (e.g.,a proxy request on behalf of a second device and/or a member device in agroup of devices). As used herein, an emergency alert is “associated”with a device or user when the emergency alert relates to an emergencyor non-emergency situation involving the device or user. In someembodiments, an emergency alert comprises data associated with a device(or user thereof). In some embodiments, an emergency alert comprisesdata associated with an electronic device sending the alert or anotherdevice. For example, in some embodiments, an emergency alert comprisesdata associated with a device, wherein the data set comprises currentand/or past location data. In another example, the data set comprisescurrent and/or past health data associated with the user of anelectronic device. In other embodiments, an emergency alert is sentand/or received separately from data associated with a device. Forexample, in some embodiments, an alert is sent first, and the recipientsubsequently queries the device that sent the alert for data associatedwith the emergency and/or device or user involved in the emergency aspart of an emergency flow script.

As used herein, a “first responder” refers to any person or personsresponsible for addressing an emergency situation. A first responder isoptionally referred to as an “emergency responder.” In some embodiments,a first responder refers to government personnel responsible foraddressing an emergency situation. In some embodiments, a firstresponder is responsible for a particular jurisdiction (e.g., amunicipality, a township, a county, etc.). In some embodiments, a firstresponder is assigned to an emergency by an emergency dispatch center(hereinafter, “EDC”). In some embodiments, a first responder responds toa request for emergency assistance placed by a user via a usercommunication device. In some embodiments, a first responder includesone or more firefighters, police officers, emergency medical personnel,community volunteers, private security, security personnel at auniversity, or other persons employed to protect and serve the publicand/or certain subsets of the population.

As used herein, a “recipient” refers to one or more persons, services,or systems that receive a request for assistance (e.g., an emergencyalert). The recipient varies depending on the type of request. In someembodiments, a recipient is an emergency service. In some embodiments, arecipient is an emergency service when the request for assistancepertains to an emergency (e.g., a tier 2 emergency). In someembodiments, a recipient is an emergency management system. In someembodiments, a recipient is an emergency dispatch center (e.g., a publicsafety answering point or PSAP). In some embodiments, a recipient is anemergency dispatch center, wherein the request is first routed throughan emergency management system (e.g., request is sent to the EMS, butultimately is sent to an EDC). In some embodiments, a recipient is adispatcher or call taker associated with a particular ESP such as aPSAP. In some embodiments, the recipient is located on-site at the ESP(e.g., PSAP station) or is working remotely (e.g., at home). In someembodiments, a recipient is a first responder (e.g., a communicationdevice of a first responder). In some embodiments, a recipient is anassociated device of a user or an account associated with the user. Insome embodiments, a recipient is a non-emergency service or personnel,for example, a relative or friend. In such situations, a user of acommunication device (or member device or second device) does notrequire emergency assistance, but does need help.

As used herein, a “user” refers to one or more person or personsassociated with a system, server, or device (e.g., electronic device,member device, second device, device of a first responder, etc.). Insome embodiments, a user is an administrator and/or authorized user whohas authorization for generating or customizing an emergency flowscript. In some embodiments, the administrator and/or authorized userworks for or acts on behalf of an organization that utilizes thesystems, servers, devices, methods, and media of the instant applicationfor managing emergency communications. In some embodiments, theorganization is a public or private organization. In some embodiments,the organization provides a transportation service (e.g., taxi company,ride-sharing company, shipping company, railroad company, etc.). In someembodiments, a user utilizes a device to send an emergency alert orrequest for assistance. In some embodiments, user refers to one or morepersons who are paid subscribers of a network access service, forexample, cellular service subscribers. In some embodiments, a userrefers to anyone who gains access to a network via a router, forexample, a Wi-Fi router, and is not a paid subscriber of any accessservice. In some embodiments, a device associated with a user is adevice carried or worn on the person of the user (e.g., a phone orwearable device). In some embodiments, a device associated with a useris not carried or worn on the person of the user (e.g., a home securitysensor or camera installed in the home of the user, a vehicle trackingsystem installed in a vehicle of the user, etc.).

As used herein, “data” refers to a collection of information about oneor more entities (e.g., user of a user communication device) and/or anenvironment that pertains to characteristics of the one or moreentities. In some embodiments, an entity is a person such as a user. Insome embodiments, an entity is a thing (e.g., a house). For example, insome embodiments, data comprises sensor data from home sensorsassociated with a house. In this example, the data is also associatedwith one or more persons (e.g., the homeowner(s) and/or inhabitant(s)).In some embodiments, data refers to meta-data. In some embodiments, datacomprises health information about the user of a communication device.In some embodiments, data comprises information about the surroundingenvironment of the user of the user communication device (e.g.,surrounding temperature, location, elevation, barometric pressure,ambient noise level, ambient light level, surrounding geography, etc.).In some embodiments, data comprises information about other users thatis pre-stored in a device or in a database (e.g., a database within agroup of devices who are related to the user of the user communicationdevice as predefined by the user). In some embodiments, the data setcomprises information from two or more users of user communicationdevices, wherein each user is affected by an emergency situation. As anexample, two unrelated users are involved in a vehicular collision, andeach user sends a separate emergency alert (for traffic accident) usinghis/her communication device. In this example, the separate emergencyalerts are associated (e.g., by an emergency management system and/oremergency dispatch center) with the same emergency based on theproximity of time, location, and emergency indication of the emergencyrequests. As a result, the data set for this accident comprisesinformation from both user communication devices. In this example, thedata set comprises location data from both devices (e.g., GPScoordinates), biosensor data for one or both devices (e.g., biosensordata such as heart rate and blood pressure can be important in case ofinjury), and information about the vehicle driven by each user (e.g.,make, model, and year of manufacture information stored on the device).In some embodiments, data comprises current data. In furtherembodiments, current data comprises information that is equal to or lessthan 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19,20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 35, 40, 45, 50, 55, or 60minutes old, including increments therein. In further embodiments,current data comprises information that equal to or less than 1, 2, 3,4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22,23, or 24 hours old. In some embodiments, data comprises historicaldata. In further embodiments, historical data comprises information thatis equal to or more than 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14,15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 35, 40,45, 50, 55, or 60 minutes old, including increments therein. In furtherembodiments, historical data comprises information that equal to or morethan 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19,20, 21, 22, 23, or 24 hours old. In some embodiments, the age ofinformation is calculated from the date the information is firstcollected (e.g., when a sensor first detects a sensed parameter such as,for example, heart rate).

As used herein, “health data” refers to medical information associatedwith a user of a device. In some embodiments, health data comprisesmedical history such as, for example, past illnesses, surgery, foodand/or drug allergies, diseases, disorders, medical diagnosticinformation (e.g., genetic profile screen), or any combination thereof.In some embodiments, health data comprises family medical history (e.g.,family history of breast cancer). In some embodiments, health datacomprises current health information such as, for example, currentsymptoms, current medications, and/or current illnesses or diseases. Insome embodiments, health data comprises user age, height, weight, bloodtype, and/or other biometrics. In some embodiments, medical historycomprises medical information that is equal to or more than 1, 2, 3, 4,5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23,or 24 hours old. In some embodiments, medical history comprises medicalinformation that is equal to or more than 1, 2, 3, 4, 5, 6, 7, 8, 9, 10,11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28,29, or 30 days old. In some embodiments, current health informationcomprises information that is equal to or less than 1, 2, 3, 4, 5, 6, 7,8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, or 24hours old. In some embodiments, current health information comprisesmedical information that is equal to or less than 1, 2, 3, 4, 5, 6, 7,8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25,26, 27, 28, 29, or 30 days old.

As used herein, “user data” refers to general information associatedwith a user of a device. In some embodiments, user data comprises useridentity, user name, height, weight, eye color, hair color, ethnicity,national origin, religion, language(s) spoken, vision (e.g., whetheruser needs corrective lenses), home address, work address, occupation,family information, user contact information, emergency contactinformation, social security number, alien registration number, driver'slicense number, vehicle VIN, organ donor (e.g., whether user is an organdonor), or any combination thereof. In some embodiments, user data isobtained via user input.

As used herein, “sensor data” refers to information obtained or providedby one or more sensors. In some instances, a sensor is associated with adevice (e.g., user has a communication device with a data link viaBluetooth with a wearable sensor, such as, for example, a heart ratemonitor or a pedometer). Accordingly, in some embodiments, the deviceobtains sensor data from the sensor (e.g., heart rate from the heartrate monitor or distance traveled from the pedometer). In someinstances, the sensor data is relevant to an emergency situation (e.g.,heart rate during a cardiac emergency event). In some embodiments, asensor and/or sensor device comprises an acoustic sensor, abreathalyzer, a carbon dioxide sensor, a carbon monoxide sensor, aninfrared sensor, an oxygen sensor, an ozone monitor, a pH sensor, asmoke detector, a current sensor (e.g., detects electric current in awire), a magnetometer, a metal detector, a radio direction finder, avoltage detector, an air flow meter, an anemometer, a flow sensor, a gasmeter, a water meter, a Geiger counter, an altimeter, an air speedindicator, a depth gauge, a gyroscope, a compass, an odometer, a shockdetector (e.g., on a football helmet to measure impact), a barometer, apressure gauge, a thermometer, a proximity sensor, a motion detector(e.g., in a home security system), an occupancy sensor, or anycombination thereof, and in some embodiments, sensor data comprisesinformation obtained from any of the preceding sensors. In someembodiments, one or more sensors are physically separate from a userdevice. In further embodiments, the one or more sensors authorize theuser device to obtain sensor data. In further embodiments, the one ormore sensors provide or send sensor data to the user deviceautonomously. In some embodiments, the user device and the one or moresensors belong to the same group of devices, wherein member devices areauthorized to share data. In some embodiments, a user device comprisesone or more sensors (e.g., user device is a wearable device having asensor or sensing component).

As used herein, an “emergency data field” or “data field” is anindividual data type that can be received, stored, or shared by anemergency management system. In some embodiments, emergency data fieldsinclude individual types of health data, user data, or sensor data, asdescribed above. For example, emergency data fields may include, but arenot limited to, name, age, gender, height, weight, ethnicity, heartrate, home address, work address, current location, historicallocations, phone number, email address, vehicle color, vehicle model,license plate number, or emergency contacts.

In some embodiments, a data field may be selected or deselected by anadministrator. In some embodiments, some data fields are anchor datafields that cannot be deselected (e.g., lat-lon) because it isconsidered to be critical information that should always be accessible.In some embodiments, data fields come with default settings (selected ordeselected), which may be customized by an ESP administrator.

As used herein an “emergency data category” or “data category” is alogical grouping of one or more emergency data fields. For example, insome embodiments, Personal Information is an emergency data categorythat includes emergency data fields such as name, age, gender, height,weight, ethnicity, home address, and work address. In some embodiments,data received by the emergency management system is tagged withemergency data fields before the data is sent to the emergencymanagement system. In some embodiments, data received by the emergencymanagement system is tagged with emergency data fields by the emergencymanagement system after the data is received. In some embodiments, datareceived by the emergency management system is tagged with emergencydata fields and emergency data categories. In some embodiments, anemergency data field is associated with one or more emergency datacategories within the emergency management system.

In some embodiments, a data category may be selected or deselected by anadministrator. In some embodiments, some data categories are anchor datafields that cannot be deselected (e.g., location info in FIG. 5E)because it is considered to be critical information that should alwaysbe accessible. In some embodiments, data categories come with defaultsettings (selected or deselected), which may be customized by an ESPadministrator.

As used herein, a “role” is an indicator, a parameter, tag, identifier,or any functional equivalent, associated with an account that indicatesa level of access to emergency data for the associated account. In someembodiments, a role is associated with one or more emergency data fieldsor emergency data categories. In some embodiments, a particular role maybe associated with a plurality of different accounts at the sameemergency service provider (ESP). For example, in some embodiments, an“Admin” (or “administrator”) role may be associated with multipleaccounts for multiple respective users at the same public safetyanswering point (PSAP). In some embodiments, a particular role may beassociated with a plurality of different accounts across different ESPs.For example, in some embodiments, an “Agent” role may be associated withmultiple accounts for multiple respective users at a first PSAP as wellas multiple accounts for multiple respective users at a second PSAP.Different roles may represent different levels of access to emergencydata. For example, an Admin role may have a higher level of access(e.g., access to more emergency data fields or emergency datacategories) than an Agent role. In this way, roles may be used tocontrol differential access to emergency data. In some embodiments,roles may be created, edited, or stored within a management portal, asdescribed below.

As used herein, “communication link” refers to a communication pathwayfrom a device (e.g., communication device) to another device or to anintermediate device (e.g., a router) such as over a network. In someembodiments, the communication device establishes a communication linkwith another device or an intermediate device to transfer information(e.g., a location of the device) or to obtain information from arecipient such as, for example, location of a first responder assignedto a request for assistance associated with the communication device(e.g., device of first responder). In some embodiments, a communicationlink refers to the point-to-point communication channels, point-to-pointand end-to-end data sessions, and/or the physical hardware facilitatingthe communication channel(s) (e.g., antennas used tocommunicate/transmit information). In some embodiments, a data sessioncomprises session parameters and the network route taken from one deviceto another device.

Modern communication devices, for example, smart phones, tabletcomputers, wearable communication devices, smart sensor devices and/orsystems are often equipped with a variety of features for determininglocation information of the communication device using, for example,GPS, or triangulation with cellular phone towers. Modern communicationdevices also often include functionality to store data regarding a userof the communication device, for example, health information about theuser.

In some embodiments, the communication device (or communication moduleof the device) communicates with a recipient through one or more datachannels. In some embodiments, the recipient is an emergency managementsystem. In some embodiments, the EMS routes communications to an EDC. Infurther embodiments, the EMS establishes a first data channel with thecommunication device and a second data channel between the EMS and theEDC, wherein the EMS bridges the first and second data channels toenable the communication device and the EDC to communicate. In someembodiments, the EMS converts data (e.g., data set) from thecommunication device into a format suitable for the EDC (e.g., analog ordigital, audio, SMS, data, etc.) before sending or routing the formatteddata to the EDC. In some embodiments, the EMS routes communications to adevice associated with a first responder. In some embodiments, thecommunication device relays additional communications, information,and/or data sent or shared between member devices in the group ofdevices to the EMS or EDC after a request for assistance has been sent.In further embodiments, the additional information is relayed to the EMSor EDC after the request for assistance has been sent in order toprovide current information that is relevant to the request. Forexample, in some instances, communications between member devicescontain information relevant to the emergency (e.g., information thatthe user of member device who is experiencing a medical emergencysuffers from diabetes). Accordingly, in some embodiments, theinformation is sent autonomously, at request of a user of thecommunication device, or at request of the recipient (e.g., EMS, EDC,first responder, etc.).

Electronic Device, Emergency Management System, and Emergency ServiceProvider

In certain embodiments, disclosed herein are devices, systems, andmethods for managing emergency data for emergency response. FIG. 1Adepicts diagrams of (i) an electronic device 110 and (ii) an emergencymanagement system (EMS) 120 in accordance with one embodiment. In someembodiments, the electronic device 110 is a digital processing devicesuch as a communication device (e.g., mobile or cellular phone,computer, laptop, etc.). In some embodiments, the electronic device is awearable device (e.g., a smartwatch). In some embodiments, theelectronic device is an Internet of Things (IoT) device, such as a homeassistant (e.g., an Amazon Echo) or a connected smoke detector (e.g., aNest Protect smoke and carbon monoxide alarm). In some embodiments, theelectronic device is a walkie-talkie or two-way radio.

In some embodiments, the electronic device 110 includes a display 111, aprocessor 112, a memory 113 (e.g., an EPROM memory, a RAM, or asolid-state memory), a network component 114 (e.g., an antenna andassociated components, Wi-Fi adapters, Bluetooth adapters, etc.), a datastorage 115, a user interface 116, an emergency alert program 117, oneor more location components 118, and one or more sensors 119. In someembodiments, the processor 112 is implemented as one or moremicroprocessors, microcomputers, microcontrollers, digital signalprocessors, central processing units, state machines, logic circuitries,and/or devices that manipulate signals based on operationalinstructions. Among other capabilities, the processor 112 is configuredto fetch and execute computer-readable instructions stored in the memory113.

In some embodiments, the display 111 is part of the user interface 116(e.g., a touchscreen is both a display and a user interface in that itprovides an interface to receive user input or user interactions). Insome embodiments, the user interface 116 includes physical buttons suchas an on/off button or volume buttons. In some embodiments, the display111 and/or the user interface 116 comprises a touchscreen (e.g., acapacitive touchscreen), which is capable of displaying information andreceiving user input. In some embodiments, the communication deviceincludes various accessories that allow for additional functionality. Insome embodiments, these accessories (not shown) include one or more ofthe following: a microphone, a camera, speaker, a fingerprint scanner,health or environmental sensors, a USB or micro-USB port, a headphonejack, a card reader, a SIM card slot, or any combination thereof. Insome embodiments, the one or more sensors include, but are not limitedto: a gyroscope, an accelerometer, a thermometer, a heart rate sensor, abarometer, or a hematology analyzer. In some embodiments, the datastorage 115 includes a location data cache 115 a and a user data cache115 b. In some embodiments, the location data cache 115 a is configuredto store locations generated by the one or more location components 118.

In some embodiments, the emergency alert program 117 is an emergencyresponse application or emergency response mobile application. In someembodiments, the emergency alert program 117 is configured to recorduser data, such as a name, address, or medical data of a user associatedwith the electronic device 110. In some embodiments, the emergency alertprogram 117 is configured to detect when an emergency request isgenerated or sent by the electronic device 110 (e.g., when a user usesthe electronic device 110 to make an emergency call). In someembodiments, in response to detecting an emergency request generated orsent by the electronic device 110, the emergency alert program isconfigured to deliver a notification to the EMS 120. In someembodiments, the notification is an HTTP post containing informationregarding the emergency request. In some embodiments, the notificationincludes a location (e.g., a device-based hybrid location) generated byor for the electronic device 110. In some embodiments, in response todetecting an emergency request generated or sent by the electronicdevice 110, the emergency alert program is configured to deliver userdata to the EMS 120.

In some embodiments, as depicted in FIG. 1A, the emergency managementsystem (EMS) 120 includes an EMS operating system 124, an EMS CPU 126,an EMS memory unit 127, an EMS communication element 128, and one ormore software modules 129. In some embodiments, the EMS CPU 126 isimplemented as one or more microprocessors, microcomputers,microcontrollers, digital signal processors, central processing units,state machines, logic circuitries, and/or devices that manipulatesignals based on operational instructions. Among other capabilities, theEMS CPU 126 is configured to fetch and execute computer-readableinstructions stored in the EMS memory unit 127. The EMS memory unit 127optionally includes any computer-readable medium known in the artincluding, for example, volatile memory, such as static random-accessmemory (SRAM) and dynamic random-access memory (DRAM), and/ornon-volatile memory, such as read-only memory (ROM), erasableprogrammable ROM, flash memories, hard disks, optical disks, andmagnetic tapes. The EMS memory unit 127 optionally includes modules,routines, programs, objects, components, data structures, etc., whichperform particular tasks or implement particular abstract data types.

In some embodiments, the EMS 120 includes one or more EMS databases 122,one or more servers 123, and a clearinghouse 150. In some embodiments,the clearinghouse 150, as described in further detail below, is aninput/output (I/O) interface configured to manage communications anddata transfers to and from the EMS 120 and external systems and devices.In some embodiments, the clearinghouse 150 includes a variety ofsoftware and hardware interfaces, for example, a web interface, agraphical user interface (GUI), and the like. The clearinghouse 150optionally enables the EMS 120 to communicate with other computingdevices, such as web servers and external data servers (not shown). Insome embodiments, the clearinghouse 150 facilitates multiplecommunications within a wide variety of networks and protocol types,including wired networks, for example, LAN, cable, etc., and wirelessnetworks, such as WLAN, cellular, or satellite. In some embodiments, theclearinghouse 150 includes one or more ports for connecting a number ofdevices to one another or to another server. In some embodiments, theclearinghouse 150 includes one or more sub-clearinghouses, such aslocation clearinghouse 150 a and additional data clearinghouse 150 b,configured to manage the transfer of locations and additional data,respectively. In some embodiments, the EMS 120 additionally includes anemergency data management portal 161 used to manage the retrieval ofemergency data from the EMS 120, as described below.

In some embodiments, as depicted in FIG. 1B, an ESP is a public safetyanswering point (PSAP) system 130 that includes one or more of a display131, a user interface 136, at least one central processing unit orprocessor 132, a network component 135, an audio system 134 (e.g.,microphone, speaker and/or a call-taking headset), and a computerprogram such as a PSAP Emergency Display Application or Location DisplayProgram 139. In some embodiments, the PSAP application or program 139comprises one or more software modules 140. In some embodiments, thePSAP system 130 comprises a database of emergency responders 137, suchas medical assets, police assets, fire response assets, rescue assets,safety assets, etc.

In some embodiments, as depicted in FIG. 1B, the PSAP application orprogram 139 installed on a PSAP system 130 comprising a software module140 is a call taking module 145, an ESP display module 146, asupplemental or updated information module 147, or a combinationthereof. In some embodiments, the PSAP application 139 displays theinformation on a map (e.g., on the display 131). In some embodiments,location and supplemental information is displayed for emergency serviceproviders (e.g., police, fire, medical, etc.) and/or responders on theirdevices. It is contemplated that responder devices have optionallyinstalled a responder device program (not shown) similar to PSAP displaymodule 146. In some embodiments, the responder device program displaysthe emergency location on a map.

Emergency Clearinghouse

In some embodiments, as described above, the emergency management system(EMS) 120 includes a clearinghouse 150 (also referred to as an“Emergency Clearinghouse”) for storing and retrieving emergency data. Insome embodiments, the clearinghouse 150 includes a locationclearinghouse 150 a and an additional data clearinghouse 150 b. In otherembodiments, additional data and location data (e.g., emergency data)are stored in one or more databases in a distributed manner. In someembodiments, the emergency data is stored in an external or third-partyserver that is accessible to the EMS 120. The clearinghouse 150optionally functions as an interface that receives and stores emergencydata from electronic or communication devices that are then retrieved,transmitted, and/or distributed to recipients (e.g., emergencypersonnel) before, during, or after emergencies. As described above, theclearinghouse optionally receives emergency data from electronic orcommunication devices such as mobile phones, wearable devices, laptop ordesktop computers, personal assistants, intelligent vehicle systems,home security systems, IoT devices, camera feeds, and other sources. Asdescribed above and below, emergency data optionally consists oflocations or additional data such as medical history, personalinformation, or contact information. In some embodiments, during anemergency, an emergency service provider ESP (e.g., a public safetyanswering point (PSAP)) queries the clearinghouse 150 for emergency datapertaining to an emergency. The clearinghouse 150 then identifies theemergency and any emergency data pertaining to the emergency storedwithin the clearinghouse 150 and transmits the pertinent emergency datato the requesting ESP. Accordingly, in some embodiments, theclearinghouse 150 acts as a data pipeline for ESPs otherwise withoutaccess to emergency data that is critical to most effectively andefficiently responding to an emergency. Accordingly, location datastored within the clearinghouse 150 allows emergency responders toarrive at the scene of an emergency faster, and additional data storedwithin the clearinghouse 150 allows emergency responders to be betterprepared for the emergencies they face.

For example, in one embodiment, an emergency alert is triggered by anelectronic device 110 (e.g., by pressing a soft button, a physicalbutton, voice command, or gesture) or autonomously based on sensor data(e.g., smoke alarms). In this example, the user then confirms theemergency and/or provides authorization for sending the emergency alert.Emergency data, such as an enhanced location and additional dataregarding the user (e.g., the user's medical history) is delivered bythe electronic device 110 to the EMS 120 and stored in the clearinghouse150 (e.g., in the location clearinghouse 150 a and the additional dataclearinghouse 150 b). In some embodiments, the EMS 120 or clearinghouse150 formats the emergency data into a format that is compatible withindustry standards for storing and sharing emergency data. For example,the emergency data is formatted to be compatible with National EmergencyNumber Association (NENA) standards. A requesting party (such as an ESPresponding to the emergency alert) then queries the clearinghouse 150with an emergency data request (such as a HTTP GET request). In someembodiments, the emergency data request is in the form of the LocationInformation Server (LIS) protocol. In response to the emergency datarequest, the EMS 120 or clearinghouse 150 sends an appropriate responseincluding relevant emergency data to the requesting party via anencrypted pathway. In some embodiments, the emergency data request is inthe form of HTTP-Enabled Location Delivery (HELD) and the response fromthe EMS 120 or clearinghouse 150 is in the form of Presence InformationData Format Location Object (PIDF-LO). In some embodiments, theemergency data request includes an authorization code (also referred toas an “authorization token”) in the body, header, or metadata of therequest, and the EMS 120 checks that the authorization code is activebefore providing a response to the requesting party. In someembodiments, authorization is provided in the “Authorization” header ofthe emergency data request using HTTP Basic Authentication. For example,in some embodiments, authorization is base64-encoded user name andpassword for an account associated with the requesting party.

In some embodiments, as described below, the appropriate response to anemergency data request from a requesting party (e.g., an ESP) isdetermined by an emergency data management portal 161 (also referred toas a “management portal”). In some embodiments, the emergency datarequest includes credentials or an access key associated with therequesting party, and consults the management portal to determine anappropriate response (e.g., which categories of emergency data should besent) based on the credentials or access key associated with therequesting party. In some embodiments, emergency data requests are sentover public networks using API access keys or credentials. In someembodiments, Transport Layer Security (TLS) is used in the requests andresponses from the EMS 120 for encryption security. In some embodiments,the call taking module 145 includes a call-handling application, whichis provided by a third-party vendor. In some embodiments, the calltaking module 145 or call handling-application is an emergency responseapplication. In some embodiments, the call taking module 145 orcall-handling application is an emergency response application that doesnot include a management portal or an enhanced data display. In someembodiments, in which an emergency response application does not includea management portal or an enhanced data display, the management portalor enhanced data display can be accessed through an internet browser,either within or outside of the emergency response application. In someembodiments, an ESP personnel interacts with the call-handlingapplication to send an emergency data request to the EMS 120. In someembodiments, the response from the EMS 120 is displayed at the ESPdisplay 131.

In some embodiments, an emergency alert or the electronic device 110from which the emergency alert was generated is associated with a phonenumber. A request from a requesting party for a location of anelectronic device 110 associated with the phone number “+1-555-555-5555”is shown below. Although not shown, credentials or an access keyassociated with the requesting party are optionally provided in theheader of the request (which is optionally encrypted for security).

  <?xml version=″1.0″?> <locationRequestxmlns=″urn:ietf:params:xml:ns:geopriv:held″>  <locationraTypeexact=″false″>   any  </locationType>  <devicexmlns=″urn:ietf:params:xml:ns:geopriv:held:id″>  <uri>tel:+15555555555</uri>  </device> </locationRequest>

An example of a LIS response from the EMS 120 in a standard formatcompatible with industry standards, PIDF-LO, is shown below. If therequest includes an inactive or expired credential or access key, anerror response will be generated.

 <?xml version=″1.0″ encoding=″utf-8″?>  <held:locationResponsexmlns:gbp=″urn:ietf:params:xml:ns:  pidf:geopriv10:basicPolicy″ xmlns:gp=″urn:ietf:params:xml:ns:pidf:geopriv10″ xmlns:gs=″http://www.opengis.net/pidflo/1.0″ xmlns:pidf=″urn:ietf:params:xml:ns:pidf″ xmlns:gml=″http://www.opengis.net/gml″ xmlns:held=″urn:ietf:params:xml:ns:geopriv:held″>  <held:locationUriSet expires=″2016-11-10 01:31:21.123713″>   <held:locationURI>   https://api-sandbox.rapidsos.com/v1/location/lbyr/?ref=c786f6b9-5e06-4611-a1c9-fbf9333e5652    </held:locationURI>  </held:locationUriSet>   <pidf:presence entity=″tel:+15555555555″>   <pidf:tuple id=″vcefda6f4-ec1c-4721-9f41-225d5ff38c09″>    <pidf:status>      <gp:geopriv>       <gp:location-info>       <gs:Circle>         <gml:pos>37.4219983 -122.084</gml:pos>        <gs:radius uom=″urn:ogc:def:uom:EPSG::9001″>        20.0</gs:radius>        </gs:Circle>        <ca:civicAddressxml:lang=″en″>         <ca:A1>CA</ca:A1>         <ca:A3>MountainView</ca:A3>         <ca:RD>Amphitheatre</ca:RD>        <ca:STS>Pkwy</ca:STS>         <ca:HNO>1600</ca:HNO>        <ca:PC>94043</ca:PC>         <ca:BLD>Google Bldg 40</ca:BLD>       </ca:civicAddress>       </gp:location-info>      <gp:usage-rules>        <gbp:retransmission-allowed>       false</gbp:retransmission-allowed>       </gp:usage-rules>     </gp:geopriv>     </pidf:status>     <pidf:timestamp>    2016-09-15T23:59:46.778000+00:00     </pidf:timestamp>   </pidf:tuple>   </pidf:presence>  </held:locationResponse>

In some embodiments, as described above, emergency data includeslocations and additional data. In some embodiments, emergency dataincludes one or more emergency data fields (also referred to as “datafields”). In some embodiments, the emergency data fields include:service data reference, full name, email, emergency contacts, addresses,language, occupation, phone numbers, websites, gender, height, weight,ethnicity, profile picture, allergies, medical conditions, medications,disabilities, blood type, medical notes, birthday, and additionalcomments. In some embodiments, emergency data fields are tagged withtags for specific types of data such as “demographics” or “medicaldata.” For example, in some embodiments, gender, height, weight,ethnicity, profile picture (image-url) are tagged as demographic data.In some embodiments, medical data protected under HIPAA and other lawsare tagged as “HIPAA” or “private.” In some embodiments, medical dataincludes information on one or more of allergies, medical condition(s)or illness(es), medication(s), disabilities, blood type, medicalnote(s), and other medical information. In some embodiments, medicalinformation protected under HIPAA are encrypted and/or anonymized. Insome embodiments, some data are tagged as “general” or another similartag, wherein access is not specifically restricted. In some embodiments,as described below, emergency data fields with common tags are groupedinto emergency data categories. For example, in some embodiments, allemergency data fields tagged as demographic data (e.g., gender, height,weight, ethnicity, etc.) are grouped into a “demographics” emergencydata category. In some embodiments, an emergency data category includesa plurality of emergency data fields. In some embodiments, an emergencydata category includes only a single emergency data field.

An example of an emergency data request for additional data from arequesting party for an electronic device 110 associated with the phonenumber “+1-777-999-7777” is shown below. Although not shown, credentialsor an access key associated with the requesting party are optionallyprovided in the header of the request.

http://api-demo.rapidsos.com/v1/adr/?caller_id=17779997777&section=device_info

An example of a response to an additional data response from the EMS 120in a standard format compatible with industry standards, PIDF-LO, isshown below. In some embodiments, if the request includes an inactive orexpired access key or set of credentials, an error response will begenerated.

HTTP/1.1 200 OK Date: Tue, 01 Dec 2016 23:27:30 GMT Content-Length: 489Content-Type: application/EmergencyCallData.DeviceInfo+xml<dev:EmergencyCallData.DeviceInfo xmlns:dev=″urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo″ <dev:DataProviderReference>d4b3072df.201409182208075@example.  org

In some embodiments, when the emergency data is stored at a third-partyserver and receives a request for emergency data from the EMS 120, as adatabase query, the third-party server formats the requested emergencydata and stores this information in an alternate database, and forwardseither a response or a reference to the alternate database for accessingthe emergency data requested by the EMS 120, which is provided to thePSAP 130 over a hybrid analog and/or a data communication channel,depending on the capabilities of PSAP 130. In some embodiments, thethird-party server stores the emergency data, requested by the EMS 120or directly by the PSAP 130, in the alternate database for a certainperiod of time after receiving the request for the emergency dataregarding a user and any electronic devices 110. In some embodiments,this period of time is a timer value (e.g., a timer countdown or a settime point) defined by the EMS 120 and the third-party server inconjunction with each other prior to the addition of the requestedemergency data to the alternate database at the third-party server. Insome embodiments, once the timer value has passed and no new requestsfor the emergency data pertaining to the particular user and theelectronic device 110, or other devices associated with the user, arereceived by the third-party server, then the third-party server marksthe particular alternate database entries to be deleted and waits foranother, different, time-out interval. In some embodiments, once thisparticular second time-out interval has also been completed and no newrequests for location data for the particular user or associatedelectronic devices 110 are received by the third-party server, thethird-party server removes the specific marked entries from thealternate database in the next cycle of updates for the alternatedatabase. In some embodiments, after adding the emergency data in thealternate database by the third-party server, the third-party serverkeeps updating the emergency data in the alternate database on aperiodic, or as-needed basis, for the purpose of keeping the emergencydata about the user or electronic device 110 current for providing themost recent and accurate emergency data to the EMS 120 and the PSAP 130for the purposes of responding to a request for emergency assistance. Insome embodiments, the third-party server is updated by the EMS 120 forall the emergency data pertaining to all users and their associatedelectronic devices 110 that are served by the EMS 120 at any currenttime.

In some non-emergency situations, there is a need to access locationdata, user data, emergency data or sensor data. For example, in someembodiments, a user of an electronic device 110 grants authorization tofamily members to access location data for the user. Accordingly, when afamily member requests location data for a user, access is granted ifthere is proper authorization. As another example, in some embodiments,a taxi operations company requests and obtains location data of one ormore fleet members to keep track of its vehicles (e.g., via onboardvehicle console or terminal).

Various embodiments and applications of the clearinghouse 150 aredescribed in detail herein. However, the embodiments and applicationsdescribed herein should not be considered exhaustive or limiting in anyway.

FIG. 2 depicts an embodiment of an Emergency Clearinghouse 250 forstoring and retrieving emergency data. In some embodiments, theclearinghouse 250 includes a set of ingestion modules 258 (also referredto as “ingestion modules”) and a set of retrieval modules 259 (alsoreferred to as “retrieval modules”). The set of ingestion modules 258optionally include a location ingestion module 251, an additional dataingestion module 252, and one or more other data ingestion modules 253.In some embodiments, the location ingestion module 251 is an emergencylocation service ingestion interface for posting or receiving emergencylocations. In some embodiments, the location ingestion module 251 is aREST API that receives an HTTP POST including location data when anemergency alert is generated (e.g., when an emergency call is made froma cell phone). The location data includes a location generatedconcurrently or in response to the generation of the emergency alert. Insome embodiments, the location data includes a location generated beforethe emergency alert. For example, when an emergency call is made from acell phone, thereby generating an emergency alert, the locationingestion module 251 receives a location recently generated by the phonebut before the emergency alert was generated, ensuring that a locationfor the emergency is available as quickly as possible. In someembodiments, the location data includes a device-based hybrid locationgenerated by an electronic device 210 that generated the emergencyalert. In some embodiments, the location data includes a locationgenerated by a second electronic device communicatively coupled to theelectronic device that generated the emergency alert. The locationingestion module 251 is integrated into an electronic device 210 througha mobile application installed on the device 210 or integrated into thefirmware or operating system of the electronic device 210.

In some embodiments, the location data is generated by the electronicdevice 210 before the emergency and is accessible to an ESP during anemergency. For example, a taxi company may have software that transmitsthe location of its cars or assets to the emergency clearinghouse 250preemptively. Thus, when an emergency arises, the location of theaffected taxi can be made accessible quicker to send help. In someembodiments, the location data is generated by the electronic device 210after the emergency has commenced and is made accessible to an ESPduring the on-going emergency. For example, updated location data of ahijacked taxi is also be periodically transmitted to the emergencyclearinghouse 250 and made accessible to an ESP.

In some embodiments, the additional data ingestion module 252 is aninterface for posting or receiving static or dynamic emergency profiledata (hereinafter, “additional data”). Additional data may includemedical data, personal data, demographic data, and health data. Forexample, medical data may include information relating to a person'smedical history, such as past surgeries or preexisting conditions.Personal data may include a person's name, date of birth, height,weight, occupation, address(es) (e.g., home address, work address,etc.), spoken languages, etc. Demographic data may include a person'sgender, ethnicity, age, etc. Health data may include information such asa person's blood type or heartrate. Additional data may further includedata received from connected devices such as vehicles, IoT devices, andwearable devices. For example, intelligent vehicle systems may generateand send data regarding a crash, such as the speed at which the vehiclewas moving just before the collision, where the vehicle was struck, thenumber of occupants, etc. In some embodiments, the additional dataingestion module 252 is a REST API (e.g., a JSON (JavaScript ObjectNotation) REST API). For example, in some embodiments, when an emergencycall is made from a cell phone, thereby generating an emergency alert,the cell phone receives a heartrate of the person who made the emergencycall from a smartwatch worn by the person and communicatively coupled tothe cell phone (e.g., Wi-Fi or Bluetooth connectivity). The cell phonesends the heartrate to the additional data ingestion module 252, alongwith any other additional data, in an HTTP POST. In some embodiments,the additional data ingestion module 252 is integrated into anelectronic device 210 through a mobile application installed on thedevice 210 or integrated into the firmware or operating system of theelectronic device 210. In some embodiments, additional data is sent tothe additional data ingestion module 252 from a network server. Theadditional data ingestion module 252 is accessed by any connectedplatform that receives data that might be relevant in an emergency.Connected platforms optionally send additional data to the additionaldata ingestion module 252 at any time. For example, in some embodiments,a website, web application, or mobile application integrated with theadditional data ingestion module 252 that allows users to createprofiles sends additional data included in the profiles to theadditional data ingestion module 252 every time a profile is created orupdated.

In some embodiments, the set of ingestion modules 258 includes one ormore other data ingestion modules 253. Another data ingestion module 253is optionally an interface for posting or receiving data relevant toemergencies that is not received by the location ingestion module 251 orthe additional data ingestion module 252. In some embodiments, the otherdata ingestion module 253 receives audio or video streams during anemergency from electronic or communication devices associated with theemergency or proximal to the emergency. For example, an emergency alertis generated by an intelligent vehicle system installed in a vehicle inresponse to the vehicle experiencing a collision. In this example, theemergency alert is sent to the EMS 120 by the intelligent vehicle systemor by an electronic device communicatively coupled to the intelligentvehicle system, such as a cell phone coupled to the intelligent vehiclesystem via Bluetooth. In response to generating the emergency alert, theintelligent vehicle system additionally begins streaming audio and videofrom microphones and cameras installed inside or outside of the vehicleto the clearinghouse 250 through the other data ingestion module 253. Acell phone communicatively coupled to the intelligent vehicle systemadditionally or alternatively streams audio or video from microphonesand cameras integrated into the cell phone to the clearinghouse 250through the other data ingestion module 253. In some embodiments, theone or more other data ingestion modules 253 are REST APIs that areaccessed with an HTTP POST.

After receiving the relevant data, the set of ingestion modules 258 canstore the data in one or more clearinghouse databases 257. For example,in some embodiments, the clearinghouse databases 257 includes a locationdatabase and an additional data database. In some embodiments, asdescribed above, the one or more clearinghouse databases 257 are storedon a third-party server communicatively coupled to or otherwiseaccessible by the EMS 120. In some embodiments, the set of ingestionmodules 258 tags or otherwise associates the data received by themodules with an identifier of a user or device associated with the data.For example, the set of ingestions modules 258 tag the data the receivedby the modules with a user ID number, an email address, or a phonenumber (e.g., caller ID). In some embodiments, the ingestion modules 258tag the data received by the clearinghouse 250 based on the data source(e.g., device name or type, application name, user name, phone number,corporate account, etc.).

In some embodiments, an individual or group of individuals areassociated with multiple identifiers. For example, the locationingestion module 251 receives a location generated by a phone associatedwith the phone number +1-555-555-5555, associated with John Doe. Theadditional data ingestion module 252 also receives a heartrate from asmartwatch associated with the email address johndoe@email.com, alsoassociated with John Doe. In this example, the set of ingestion modules258 tag the location with the phone number “+1-555-555-5555,” tag theheartrate with the email address “johndoe@email.com,” and associate boththe location and the heartrate with John Doe in the clearinghousedatabases 257.

The ingestion data enters the clearinghouse 250 (as shown in FIG. 2)comprises various data fields and data entries for those data fields. Insome embodiments, the clearinghouse 250 maintains a list of expecteddata fields so that the data entries can be placed under a specific datafield. In some embodiments, the data categories are selected ordeselected by the administrator of the ESP to display for a specificrole using a management portal, as described below.

In some embodiments, there are some data categories that cannot bedeselected by the administrator of the ESP (referred to as anchor datafields). Table 1 is a list of anchor data fields and an expectation(whether it will be present in the ingestion data). In some embodiments,anchor data fields must be displayed in the enhanced data display or inthe web page accessed by it. Accordingly, in such embodiments, theadministrator cannot restrict access to anchor data fields because theyare considered critical. However, as indicated in Table 1, in someembodiments, certain anchor data fields do not have available data. Insuch embodiments, when data is not available for an anchor data field,it is not displayed, or is displayed as a blank, N/A, etc. Similar toanchor data fields, there may be anchor data tags that are consideredcritical information where access cannot be restricted. For example,“location info” has been designated as an anchor data tag in FIG. 5E.

TABLE 1 Anchor Data Fields Data Field Always Present caller_id − Phonenumber of caller the Yes location record belongs to rg_address − Civicaddress of the No reverse-geocoded location latitude − EPSG:4326 ISO6709latitude Yes coordinate of the location record longitude − EPSG:4326ISO6709 Yes longitude coordinate of location record rg_likelihood −Value from 0-100 of the % No likelihood that the location record is atthis place uncertainty_radius − EPSG:9001 circular radius Yes ofuncertainty in meters uncertainty_confidence − IETF RFC7459 No definedvalue from 0-100 of the % confidence in the uncertainty radius, or nullif not reported Location_time − UNIX timestamp in UTC Yes of when thelocation was recorded on the client device

In some embodiments, as depicted in FIG. 2, the clearinghouse 250includes a set of retrieval modules 259. The set of retrieval modules259 optionally include a location retrieval module 254, an additionaldata retrieval module 255, and one or more other data retrieval modules256. In some embodiments, the location retrieval module 254 is aninterface for retrieving location data from the clearinghouse databases257. In some embodiments, the location retrieval module 254 is a JSONREST API that receives a query or request (e.g., in the form of an HTTPGET request) from a requesting party, such as an ESP. In someembodiments, the request is sent from a call-taking application (e.g.,call taking module 145) integrated into the PSAP system 130. In someembodiments, the location retrieval module 254 provides a single GETendpoint for retrieving either the latest or paginated list of locationsfor a specific caller ID (e.g., an identifier of a user or an electronicdevice associated with a user, such as a phone number). For example, asdescribed above, a phone number associated with a device 210 from whicha location was received is included in the header, body, or metadata ofthe request sent to the location retrieval module 254. The clearinghouse250 then retrieves a location or set of locations from the clearinghousedatabases 257 and deliver the location or set of locations to therequesting party. In some embodiments, the location retrieval module 254is a location information server (LIS). In some embodiments, the LIS isa NG911 standards-based XML API for the retrieval of location data fromthe clearinghouse databases 257. In some embodiments, as describedabove, the location retrieval module 254 accepts HELD requests fromrequesting parties and returns location data for a specific caller ID oranonymous reference.

As depicted in FIG. 2, the set of retrieval modules 259 optionallyinclude an additional data retrieval module 255. In some embodiments,the additional data retrieval module 255 is a JSON REST API for theretrieval of emergency or additional data. As described above,additional data optionally includes medical data, personal data,demographic data, and health data. Additional data also optionallyincludes data received from connected devices such as vehicles, IoTdevices, and wearable devices. In some embodiments, the additional dataretrieval module 255 receives a query or request (e.g., in the form ofan HTTP GET request) from a requesting party, such as an ESP. Theadditional data then retrieves additional data associated with aspecific or particular identifier of a user or an electronic deviceassociated with the user, such as a phone number, and returns the datato the requesting party. In some embodiments, the set of retrievalmodules 259 further includes one or more other data retrieval modules256, which function similarly to the location retrieval module 254 andadditional data retrieval module 255, for the retrieval of data storedin the clearinghouse databases 257 not retrieved by the locationretrieval module 254 or additional data retrieval module 255.

In some embodiments, a retrieval module within the set of retrievalmodules 259 and a corresponding ingestion module within the set ofingestion modules 258 form a sub-clearinghouse. For example, in someembodiments, location ingestion module 251 and location retrieval module254 combine to form location clearinghouse 150 a (as shown in FIG. 1B).Likewise, in some embodiments, additional data ingestion module 252 andadditional data retrieval module 255 combine to form additional dataclearinghouse 150 b. In some embodiments, a requesting party is onlygiven access to a particular sub-clearinghouse. For example, a policeofficer is only given access to the location clearinghouse 150 a, whilean EMT (emergency medical technician) is only given access to theadditional data clearinghouse 150 b. However, a requesting party isgiven differential access to the clearinghouse 150, sub-clearinghouses,particular emergency data fields, or particular emergency datacategories within the clearinghouse 150 based on any factor or set offactors. In some embodiments, as described below, a management portal isused to determine which emergency data fields or emergency datacategories are returned from the EMS 120 or clearinghouse 250 to aparticular requesting party.

ESP Integration System

FIG. 3 depicts a diagram of an emergency service provider (ESP)integration system in accordance with one embodiment. In someembodiments, an ESP integration system 360 includes an emergency datamanagement portal 361 (hereinafter, “management portal”), an emergencyservice provider (ESP) network 335, and an ESP console (or userinterface) 336. In some embodiments, the ESP console UI 336 is acomputing device at the ESP. The ESP integration system 360 additionallyor alternatively includes a third-party network or server 362, anenhanced data display 364, or a website 368. In some embodiments, asdescribed below, the various components of the ESP integration system360 function in conjunction to send requests for emergency data to theEMS 320, receive emergency data from the EMS 320, and display emergencydata from the EMS 320 to emergency personnel within the PSAP 130. Insome embodiments, the management portal 361 is additionally oralternatively included in the EMS 320. In some embodiments, as depictedin FIG. 3, the ESP integration system 360 includes only the managementportal 361, the enhanced data display 364, and the ESP console 336. Insome embodiments, wherein the ESP integration system 360 includes onlythe management portal 361, the enhanced data display 364, and the ESPconsole 336, the management portal 361 and the enhanced data display 364are included in a single web application (as described below), and theESP console 336 is a computing device at the ESP used to access the webapplication.

In some embodiments, the management portal 361 is a software module andinterface included in the EMS 320. In some embodiments, the managementportal 361 is provided by the EMS 320. In some embodiments, theinterface of the management portal 361 is embodied and accessed as awebsite, such as by navigating to a URL within a web browser. In someembodiments, the interface of the management portal 361 is embodied andaccessed as a desktop application installed on a computing device. Insome embodiments, the management portal 361 and the enhanced datadisplay 364 are included in a single, standalone website, webapplication, or desktop application (also referred to as an “emergencyresponse application”). For example, in some embodiments, an ESPpersonnel can navigate to a web application provided by the EMS 320through an ESP console UI 336 (e.g., a computer at the ESP) and accessboth the management portal 361 and the enhanced data display within theweb application. In some embodiments, the management portal 361 isaccessed by an administrator of one or more ESPs (“ESP administrator”).As described below, the ESP administrator can then select a particularESP or group of ESPs and select which emergency data fields or emergencydata categories are to be sent from the EMS 320 or clearinghouse 350 tothe particular ESP or group of ESPs in response to a request foremergency data sent from the particular ESP or an ESP included in thegroup of ESPs. In some embodiments, as described below, an ESPadministrator can further select which emergency data fields oremergency data categories are to be sent to a particular role within aparticular PSAP or group of PSAPs. In some embodiments, the managementportal 361 is entirely distinct and separate from the PSAP 130.

In some embodiments, requests for emergency data to the EMS 320 andresponses sent from the EMS 320 to the PSAP 130 are sent from andreceived at different layers or components within the ESP integrationsystem 360. In some embodiments, a request for emergency data is sentfrom a PSAP 130 at the ESP console UI 336. For example, an ESP personnelgenerates a request for emergency data by selecting a button within theESP console UI 336. Or, for example, a request for emergency data isgenerated at the ESP console UI 336 when the PSAP 130 receives a requestfor emergency assistance (e.g., when a PSAP receives a 9-1-1 call) andan ESP personnel accepts the request for emergency assistance (e.g.,when a PSAP operator answers a 9-1-1 call). In some embodiments, arequest for emergency data is generated through the enhanced datadisplay 364. In some embodiments, a request for emergency data isgenerated through an emergency response application (e.g., a web ordesktop application) that includes both a management portal 361 and anenhanced data display 364, as described below. In some embodiments,after the request for emergency data is generated, the emergency datarequest is delivered from the ESP network 335 to the EMS 320. In someembodiments, the emergency data request is first delivered from the ESPnetwork 335 to a third-party network 362 before being sent from thethird-party network 362 to the EMS 320. For example, in someembodiments, a call taking module 145 within the ESP software 140 is adesktop application (e.g., a call-taking application) provided by athird-party vendor and installed within the PSAP 130. In thisembodiment, an emergency data request is generated by an ESP personnelselecting a button within the interface of the vendor-provided desktopapplication. The emergency data request is then sent from the ESPnetwork 335 to the third-party network 362 and then to the EMS 320. Insome embodiments, an emergency data request is generated within athird-party desktop application and sent directly from the ESP network335 to the EMS 320.

In some embodiments, after the EMS 320 receives an emergency datarequest from the PSAP 130, the EMS 320 consults the management portal361 to determine which emergency data categories to send to the PSAP130. As described above, an emergency data request may include acredential or an access key associated with the PSAP 130 from which theemergency data request was sent. In some embodiments, the PSAP 130cross-references credentials provided in an emergency data request withthe management portal 361 to determine which emergency data categorieshave been selected for the PSAP 130 by an administrator of the PSAP 130,as described below. In some embodiments, as described below, anemergency data request sent to the EMS 320 by a PSAP 130 may include oneor more indicators (e.g., tags) of which emergency data fields oremergency data categories have been selected for the PSAP 130 or anindividual ESP personnel (e.g., a role assigned to an individual ESPpersonnel) associated with the PSAP 130 by an administrator of the PSAP130. In some embodiments, the management portal 361 includes amanagement portal database 369 for storing keys and roles assigned to anESP, as described below. In some embodiments, the management portaldatabase 369 stores keys and roles in a data cache for efficient recall.After determining which emergency data fields are to be sent to the PSAP130, the EMS 320 transmits emergency data to the PSAP 130 for one ormore of the emergency data fields. For example, in one embodiment, anESP administrator access the management portal 361 and selects ESP A.The ESP administrator then selects location, name, phone number, andemail address as emergency data categories to be sent to ESP A. In thisembodiment, ESP A receives an emergency alert (e.g., a 9-1-1 call) froma user and sends an emergency data request to the EMS 320. In thisembodiment, the EMS 320 receives the emergency data request from ESP A,the EMS 320 identifies ESP A as the requesting party based oncredentials included in the emergency data request. Then, in thisembodiment, the EMS 320 checks the management portal 361 to determinethat the only emergency data fields to be sent to ESP A are location,name, phone number, and email address. The EMS 320 or clearinghouse 350then references the clearinghouse databases 257 to determine what dataassociated with the emergency alert is available. In this example, theEMS 320 determines that location, name, phone number, ethnicity, andoccupation are available for the emergency alert. In this example,although ethnicity and occupation are available for the emergency alert,the EMS 320 does not return either because neither was selected to besent to ESP A. Although email address was selected by the ESPadministrator to be sent to ESP A, an email address is not returned bythe EMS 320 because an email address is not available for the emergencyalert. In this example, in response to the emergency data request sentfrom ESP A, the EMS 320 returns only a location, name, and phone numberassociated with the emergency alert to ESP A.

In some embodiments, emergency data returned by the EMS 320 in responseto an emergency data request is sent to the requesting PSAP 130 throughthe ESP network 335. In some embodiments, emergency data returned by theEMS 320 in response to an emergency data request is sent to therequesting PSAP 130 first through a third-party network 362 and thenthrough the EMS network 335. In some embodiments, the emergency datareturned by the EMS 320 is displayed at the ESP display 131 through theESP console UI 336. In some embodiments, the emergency data returned bythe EMS is displayed at the PSAP 130 through an enhanced data display364, as described below. In some embodiments, the enhanced data display364 is accessed through a website 368. In some embodiments, the enhanceddata display 364 is a standalone web application or desktop application.In some embodiments, as mentioned above, the enhanced data display 364is included with the management portal 361 in a standalone webapplication or desktop application. In some embodiments, the enhanceddata display 364 is accessed through a desktop application installed atthe PSAP 130. In some embodiments, the enhanced data display 364 isaccessed through a website 368 within a desktop application installed atthe PSAP 130. In some embodiments, the desktop application is providedby at third-party vendor.

Emergency Data Management Portal

FIGS. 4A and 4B depict diagrams of an ESP administrator, an EMS, and anESP personnel in accordance with one embodiment of the presentinvention. In some embodiments, a management portal is implemented asone or more software modules on a computing system that includes aprocessor and a non-transitory computer readable storage medium. In someembodiments, the management portal is configured to establish a role anddefine a set of emergency data fields or emergency data categories to bemade accessible for the role, as described below. In some embodiments,an ESP administrator 463 accesses an emergency data management portal(“management portal”) 461 to select emergency data categories to be sentto particular ESPs or particular personnel (“ESP personnel”) 465 withinparticular ESPs. For example, in some embodiments, an ESP administrator463 of multiple ESPs (e.g., three different PSAPs within a 30-mileradius) is given credentials (e.g., a username and password) or anaccess key to access the management portal 461. Using the credentials oraccess key, the ESP administrator 463 can log into the management portal461 and define keys (as described below) for one or more of the ESPsunder the ESP administrator's authority. After defining a key for aparticular ESP under the ESP administrator's authority, the ESPadministrator 463 can define roles (as described below) within theparticular ESP. For example, at the management portal 461, the ESPadministrator 463 optionally defines a key for a PSAP and a call-takerrole within the PSAP. After defining a particular role within aparticular ESP, the ESP administrator 463 then selects one or moreemergency data fields or emergency data categories to be sent from theEMS 420 to the particular ESP in response to an emergency data requestfrom an ESP personnel 465 having the particular role, as describedbelow. In some embodiments, the management portal establishes defaultroles and defines default sets of emergency data fields or emergencydata categories to be made accessible for the default roles, asdescribed below. In some embodiments, as depicted by FIG. 4A, when anESP personnel 465 generates and sends an emergency data request to theEMS 420, the EMS 420 determines the particular ESP that the ESPpersonnel 465 is associated with and the role of the ESP personnel 465within the particular ESP through identifiers (e.g., credentials or anaccess key) included in the emergency data request. The clearinghouse450 then references the management portal 461 to determine whichemergency data fields have been selected to be sent to the particularESP and the role of the ESP personnel 465 by the ESP administrator ofthe particular ESP. The EMS 420 then determines and returns anappropriate response to the emergency data request.

In some embodiments, as depicted by FIG. 4B, when an ESP personnel 465associated with a particular role generates and sends an emergency datarequest to the EMS 420, the emergency data request includes one or moreindicators (e.g., tags) that indicate which emergency data fields oremergency data categories have been selected for the particular role.For example, in some embodiments, the enhanced data display and themanagement portal 461 are included in a standalone web application (asmentioned above). In such an embodiment, when an ESP personnel 465 logsinto the standalone web application (such as by submitting a validusername and password), the management portal 461 identifies a roleassociated with the ESP personnel 465 and the emergency data fieldsselected for the role. The management portal 461 then returns one ormore indicators (e.g., tags) of the emergency data fields selected forthe role to the standalone web application. Then, when the ESP personnel465 generates an emergency data request through the enhanced datadisplay, the emergency data request includes the one or more indicators(e.g., tags) of the emergency data fields selected for the roleassociated with the ESP personnel 465. The clearinghouse 450 thendetermines which data fields have been selected for the role associatedwith the ESP personnel 465 using the one or more indicators instead ofreferencing the management portal 461. The EMS 420 then determines andreturns an appropriate response to the emergency data request.

FIGS. 5A and 5B illustrate an embodiment of a management portal inaccordance with one embodiment. As described above, in some embodiments,an ESP administrator accesses a management portal 561 to selectemergency data fields to be sent to particular ESPs or particularpersonnel within particular ESPs. In some embodiments, the managementportal 561 is a website or web application accessible with a URL througha web browser. In some embodiments, the management portal 561 is adesktop application. In some embodiments, an ESP administrator logs intothe management portal 561 using credentials or an access key (e.g., ausername and password). For example, in some embodiments, an ESPadministrator applies for or otherwise requests access to the managementportal 561 from a provider of the management portal. After approving theESP administrator for access to the management portal 561, the providerof the management portal provides credentials or an access key to theESP administrator that the ESP administrator uses to log into themanagement portal 561. In some embodiments, after logging into themanagement portal 561, an ESP administrator chooses between one or moreorganizations 571 under the ESP administrator's authority. For example,the ESP administrator is optionally a channel partner (e.g., a companythat manages technology installations for multiple clients or partners)that services multiple PSAPs within a state. Each PSAP under the channelpartner's management is listed within the management portal 561 as adifferent organization 571. In another example, a single organization571 oversees multiple ESPs (e.g., multiple PSAPs or fire departments),and the ESP administrator is a local or state government official taskedwith managing the multiple ESPs. In some embodiments, the ESPadministrator is only given access to a single organization 571.

In some embodiments, as depicted in FIG. 5A, after the ESP administratorlogs into the management portal 561 and an organization is selected, themanagement portal 561 displays existing keys 572 created for theorganization 571. In some embodiments, a key (or agency key) 572 is anidentifier of a particular ESP that defines both the particular ESP andthe access to emergency data for the particular ESP. In someembodiments, an ESP administrator creates a new key 572 by selecting an“Add New Key” button 574. In some embodiments, each key 572 is assignedan enabled environment 573 when the key 572 is created. In someembodiments, a key 572 is assigned an enabled environment 573 of “Test”or “Production.” In some embodiments, the definitions of keys 572assigned to the “Production” enabled environment 573 are applied to live(e.g., legitimate and real-time) emergency alerts (e.g., 9-1-1 calls)handled by the associated ESP. In some embodiments, an organization 571is allowed to have only a single key 572 assigned to the “Production”enabled environment 573. In some embodiments, the definitions of a key572 assigned to the “Test” enabled environment 573 are applied only totest or demo emergency alerts and allow an ESP to simulate handling anemergency alert with the definitions of the key 572. For example,call-takers at PSAP B traditionally only have access to a name and alocation of a caller when they receive a 9-1-1 call. However, anadministrator of PSAP B is considering allowing call-takers at PSAP B toview demographic data of callers when they receive 9-1-1 calls but isunsure how the additional data will affect the call-takers. In thisexample, the administrator of PSAP B accesses the management portal 561,selects PSAP B under organizations 571, creates a new key 572 byselecting the “Add New Key” button 574, and assigns the new key 572 tothe “test” enabled environment 573. The administrator then selectsdemographic data to be additionally sent to call-takers at PSAP B. PSAPB then executes test 9-1-1 calls with PSAP B call-takers so that thePSAP B call-takers experience having the additional demographic datawhile handling 9-1-1 calls without potentially jeopardizing realemergency situations.

In some embodiments, after creating a key 572 for a particular ESP, anESP administrator creates one or more roles 575 for the particular ESP,such as by selecting the “Add Role” button 576, as depicted in FIG. 5B.For example, as depicted in FIG. 5A, an ESP administrator can create akey 572 for a particular PSAP called “PSAP Widget.” The ESPadministrator can then create a role 575 within the “PSAP Widget” key572 called “Admin” for an administrator (e.g., the person of highestauthority) of the particular PSAP. As depicted in FIG. 5B, aftercreating a role 572, the management portal 561 displays all of theemergency data fields stored by the EMS. In some embodiments, theemergency data fields are grouped according to their tags into emergencydata categories, as described above. For example, in some embodiments,as depicted in FIG. 5B, the photo, name, gender, and ethnicity emergencydata fields are tagged as “demographics” and grouped together under a“Demographics” emergency data category. In some embodiments, anemergency data category (i.e., a group of emergency data fields) isgrouped with one or more other emergency data categories under asupergroup of emergency data categories. For example, as depicted inFIG. 5B, the “Demographics” emergency data category is grouped under a“Personal Information” supergroup of emergency data categories.

In some embodiments, a “Caller Information” supergroup includes“Personal Information,” “Medical Information,” and “Emergency Contacts”(e.g., user submitted emergency contacts) addresses) subgroups. In someembodiments, the “Personal Information” group includes the“Demographics,” “Contact Information,” and “Addresses” emergency datacategories. In some embodiments, the “Demographics” emergency datacategory includes the photo, name, gender, birth date, ethnicity,height, weight, languages, occupation, and comments emergency datafields. In some embodiments, the “Contact Information” emergency datacategory includes the email, phone number, notes, and URLs emergencydata fields. In some embodiments, the “Addresses” emergency datacategory includes user submitted addresses, such as a work or homeaddress. In some embodiments, the “Medical Information” emergency datacategory includes the allergies, disabilities, blood type, medicalconditions, notes, and medications emergency data fields. In someembodiments, the “Emergency Contacts” emergency data category includesuser submitted emergency contacts.

In some embodiments, a “Location” supergroup includes “Probable Address”and “Caller-Provided Locations” subgroups. In some embodiments, the“Probable Address” emergency data category includes the likelihood,name, address, exact location, latitude, longitude, contact, and URLemergency data fields. In some embodiments, the “Caller-ProvidedLocations” emergency data category includes the name, address, comments,URLs, and contact emergency data fields.

In some embodiments, after the management portal 561 displays all of theemergency data fields stored by the EMS, an ESP administrator thenselects emergency data fields to be made available for a role 575,thereby defining a set of emergency data fields for the role 575. Insome embodiments, an ESP administrator selects individual emergency datafields to be made available for a role. For example, as depicted in FIG.5B, the photo and gender data categories have been selected to be madeavailable for the “Admin” role. In some embodiments, an ESPadministrator selects emergency data categories supergroups of emergencydata categories to be made available for a role 575. For example, asdepicted in FIG. 5B, an ESP administrator selects the check box next tothe “Demographics” emergency data category to make all of the emergencydata fields grouped under the “Demographics” emergency data categoryavailable for the “Admin” role. In some embodiments, an ESPadministrator can define a set of emergency data fields or emergencydata categories to be made available or accessible for a role byaccepting a default set of emergency data fields or emergency datacategories presented by the management portal 561.

As depicted in FIG. 5B, an ESP administrator creates multiple roles 575within a key 572. For example, as depicted in FIG. 5B, there are threeroles 575 created for the “PSAP Widget” key 572, “Admin,” “Agent,” and“SMSRole.” The ESP administrator optionally selects different emergencydata fields to be made available for different roles 575 within the samekey 572. For example, the ESP administrator selects the “MedicalInformation” and “Locations” emergency data categories to be madeavailable for the “Agent” role, but not the “Demographics” emergencydata category. Or, for example, the ESP administrator selects only the“Contact Information” emergency data category to be made available forthe “SMSRole.” Finally, the ESP administrator optionally selects all ofthe emergency data fields available for the “Admin” role. The ESPadministrator, who typically has an intimate understanding of thehierarchy, needs, and capabilities of an ESP under the ESPsadministrator's authority, is often the person best suited to decidewhich emergency data fields or emergency data categories should be madeavailable to which roles within a particular ESP. In some embodiments,an ESP administrator accesses the management portal 561 to delete oredit a role 572.

In some embodiments, an ESP administrator names keys 572 and roles 575within the keys to match corresponding keys and roles defined in athird-party system. For example, in some embodiments, emergency datareturned by the EMS in response to an emergency data request is sent tothe requesting ESP first through a third-party network and then throughthe EMS network, as described above. In some embodiments, ESP personnelare preassigned roles within the third-party system. In such anembodiment, an ESP administrator will associate the preassigned roleswith the roles 572 created within the management portal 561, such as bynaming the roles 572 created within the management portal 561 with theexact same names as the preassigned roles. When an ESP personnelgenerates an emergency data request, the EMS then efficiently associatesa preassigned role of the ESP personnel with a role 572 created for theESP personnel within the management portal 561, as described below.

As mentioned above, in some embodiments, the management portal 561 isaccessed through a standalone website, web application, or desktopapplication. FIGS. 5C-5G illustrate an embodiment of a management portal561 accessed through a web application 580 (also referred to as an“emergency response application”). In some embodiments, as mentionedabove, the web application 580 includes the management portal 561 andthe enhanced data display. In some embodiments, the management portal561 and the enhanced data display are separately accessed throughdifferent tabs within the web application 580. In some embodiments, theweb application 580 includes a graphical user interface (GUI) thatcontains one or more pages each with their own plurality of interactiveelements, such as, but not limited to, entry fields, soft buttons,sliders, maps, images, and videos. Advantageously, because the webapplication 580 can be accessed through an internet or web browser, theweb application can be quickly and easily integrated into the systemsused by emergency service providers (e.g., PSAPs), because accessing andusing the web application 580 requires no additional software orhardware outside of standard computing devices and networks.

FIG. 5C illustrates a Users tab 582A of an embodiment of a managementportal 561 accessed through a web application 580. In some embodiments,after an account is created for the PSAP administrator to access the webapplication (as described below), the PSAP administrator can createaccounts for employees or other members of the PSAP. In someembodiments, the web application 580 will not allow a PSAP administratorto create accounts for other members of the PSAP until a request foraccess to the web application from the PSAP administrator is verified(as described below). In some embodiments, to create an account foranother member of a PSAP, the PSAP administrator can select the Userstab 582A. Selecting the Users tab 582A then prompts the web application580 to display a list of accounts associated with the particular PSAP.For example, FIG. 5C depicts a list of accounts associated with the“Georgia” PSAP, which includes a PSAP administrator account 583B, a PSAPstaff account 583C, and a second PSAP administrator account 583D. Inthis example, although the PSAP administrator account 583D is pendingapproval, the PSAP administrator account 584B and the PSAP staff account583C have already been approved. In some embodiments, as depicted inFIG. 5C, every account associated with a PSAP is assigned a role. Asdepicted, accounts 583B and 583D are assigned the Admin role whileaccount 583C is assigned the Staff role.

After selecting the Users tab 582A, a PSAP administrator can create anew account for a PSAP by selecting the Add User button 583A. In someembodiments, after selecting the Add User button 583A, the webapplication 580 prompts the PSAP administrator to select role to beassigned to the new account. In some embodiments, the PSAP administratorcan select from any role type that has been created for the particularPSAP. In some embodiments, in addition to the role, the web application580 prompts the PSAP administrator to submit an email address for theuser of the new account. Upon submission of the role and email address,the web application 580 creates a new account (e.g., within a userdatabase, as described below) and populates the new account with therole and the email address. In some embodiments, an email including aconfirmation link is sent to the email address, and the web application580 does not allow access to the new account until the confirmation linkis selected. In some embodiments, the email additionally oralternatively includes a temporary password for the new account. In someembodiments, a PSAP administrator creates an account for another memberof the PSAP before the request for access to the web application 580 isapproved. However, in some embodiments, neither the PSAP administratornor any other account created by the PSAP administrator can accessemergency data stored within the clearinghouse until after the requestfor access to the web application 580 has been approved.

In some embodiments, a PSAP administrator can access the Roles tab 582Bto create new roles for a particular PSAP or edit existing roles, asdepicted by FIGS. 5D-5F. In some embodiments, the Roles tab 582B is agraphical user interface (GUI) of a management portal. As shown in FIG.5D, two existing roles for the Georgia PSAP are displayed within theRoles tab 582B, the admin role 584A and the staff role 584B. In someembodiments, as depicted by FIG. 5D, roles for a particular PSAP aredisplayed within the Roles tab 582B as tiles that can be selected. Insome embodiments, as depicted by FIG. 5D, the tiles representing rolesdisplay the emergency data fields, or emergency data categories (i.e.,groups of emergency data fields, as described above), that the roleshave been given access to. For example, as shown in FIG. 5D, the adminrole 584A for the Georgia PSAP has been given access to the LocationInformation, Ridesharing Information, and Personal Information emergencydata categories. The staff role 584B for the Georgia PSAP has been givenaccess to the Location Information and Personal Information emergencydata categories. In some embodiments, the Roles tab 582B includes acreate new role button 585. In some embodiments, as depicted in FIG. 5E,when a tile representing a role is selected within the Roles tab 582B,the tile expands to display all of the emergency data fields oremergency data categories provided by the clearinghouse and allow a PSAPadministrator to select or deselect emergency data fields or emergencydata categories 586 to be made accessible for the role, to edit thetitle of the role in text box 586A, or to save the edited role with savebutton 586B. In some embodiments, one or more emergency data fields oremergency data categories may not be able to be deselected. For example,as shown in FIG. 5E, while Ridesharing Information is unselected(unchecked box) and Personal Information is selected (checked box),Location Information is permanently selected (filled in box) and cannotbe deselected. In some embodiments, a PSAP administrator can create anew role for a PSAP by selecting the create new role button 585. Forexample, as shown in FIG. 5F, an administrator of the Georgia PSAP cancreate a “Dispatcher” role 584C. In this example, the LocationInformation, Ridesharing Information, and Personal Information emergencydata categories have been selected to be made accessible for theDispatcher role 584C.

In providing the web application 580 to PSAPs (and the potentiallysensitive emergency data stored within the clearinghouse, by extension)in the most accessible way possible, it is advantageous to providerigorous security precautions and functions specifically created andsuited for the web application 580, as will be described below. In someembodiments, if a PSAP desires to access the emergency data storedwithin the clearinghouse, an administrator of the PSAP (hereinafter,“PSAP administrator” or “PSAP admin”) can navigate to the webapplication 580 using a URL in a standard web browser. The PSAPadministrator can then use interactive elements of the web application580 to request access to the clearinghouse using the web application580. In some embodiments, upon selecting to request access to the webapplication 580, the web application 580 prompts the PSAP administratorto submit information 587 about the PSAP through the web application580, as depicted in FIG. 5G, such as through a PSAP information tab582C. In some embodiments, the information about the PSAP includes thename of the PSAP (hereinafter, “PSAP name”) 581, a non-emergencyhardline telephone number of the PSAP (hereinafter, “non-emergencynumber”) 587A, the coverage area or jurisdiction of the PSAP 587B (e.g.,a geofence defining the authoritative region of the PSAP), and otherinformation 587C. In some embodiments, other information 587C includesat least one of a type of computer aided dispatch (CAD) system used bythe PSAP, a type of phone system used by the PSAP, a type of mappingsystem used by the PSAP, and an estimated population covered by the PSAP(i.e., an approximate number of people who reside within thejurisdiction of the PSAP). In some embodiments, the PSAP administratorcan use interactive elements to define a geofence representing thejurisdiction of the PSAP 587B, as described below. In some embodiments,the PSAP is not granted access to the web application 580 if some or allof the information 587 is not submitted by the PSAP administrator. Insome embodiments, the PSAP administrator edits or resubmits theinformation 587 about the PSAP by selecting the PSAP Information tab582C. In some embodiments, after the PSAP is granted access to the webapplication 580 and/or the clearinghouse, the PSAP administrator cancreate accounts for other employees or members of the PSAP by selectingthe Users tab 582A, as described above.

Emergency Data Management

FIG. 6 depicts a diagram of an emergency data management process inaccordance with one embodiment. In some embodiments, an electronicdevice 610 transmits data before, during, or after emergency situationsto an emergency management system (EMS) 620. The data includes locationsand additional data, as described above. In some embodiments, asdescribed above, the EMS 620 stores the data in an EmergencyClearinghouse 650 for retrieval by emergency service providers (ESP) 630a-630 n. ESPs 630 a-630 n can request and receive data from the EMS 620during emergency situations to aid in quickly, efficiently, andeffectively respond to emergencies.

In some embodiments, an ESP administrator 663 access a management portal661 to select emergency data fields to be sent to particular PSAPs 630or particular ESP personnel within the particular ESPs 630 a-630 n, asdescribed above. For example, as depicted by FIG. 6, an ESPadministrator 663 has authority over ESPs 630 a-630 n. The ESPadministrator 663 accesses the management portal 661 and select aparticular ESP 630 a-630 n under the ESP administrator's authority, suchas ESP 630 b, and select one or more emergency data fields to be madeavailable for ESP 630 b, as described above. In some embodiments, whenan emergency call is made from an electronic device 610, an emergencyalert 667 is generated and delivered to both the EMS 620 and an ESP 630a-630 n. In addition to the emergency alert, the electronic device 610sends data to the EMS 620, such as through the clearinghouse 650, asdescribed above. This data can include locations, personal information,medical information, heath data, etc. In some embodiments, the EMS 620or clearinghouse 650 may also contains preexisting (e.g., before theemergency alert is generated and sent) data associated with theelectronic device 610 or a user of the electronic device 610. In someembodiments, after receiving the emergency alert, the ESP 630 a-630 nsends an emergency data request to the EMS 620 or clearinghouse 650 torequest emergency data associated with the emergency alert. The EMS 620or clearinghouse 650 then gathers emergency data associated with theemergency alert and returns the emergency data available for theemergency data fields selected to be made available for the ESP 630a-630 n at the management portal 661.

FIG. 7 depicts a flow diagram of an emergency data management process inaccordance with one embodiment. In one example, an ESP administrator 763accesses the management portal 761 and selects locations and personalinformation (as described above) to be made available for the PSAP 730(or a particular member of the PSAP 730). In this example, an electronicdevice 710 generates an emergency alert 767 and simultaneously sends theemergency alert 767 to both the EMS 720 and the PSAP 730. In addition tothe emergency alert 767, the electronic device 710 sends a device-basedhybrid location generated simultaneously with the emergency alert 767,demographic data associated with a user of the electronic device 710,and a list of emergency contacts to the EMS 720. In this example, theEMS 720 already contains a medical history of the user associated withthe electronic device 710 and a user submitted home address of the user.After receiving the emergency alert 767, the PSAP 730 sends an emergencydata request to the EMS 720 or the clearinghouse 750. The EMS 720 thengathers any and all data stored within the EMS 720 associated with theemergency alert 767. In this example, the EMS 720 is able to gather thedevice-based hybrid location, the demographic data associated with theuser of the electronic device 710, the list of emergency contacts, themedical history of the user, and the user submitted home address.However, the ESP administrator 763 only selected locations and personalinformation to be made available to the PSAP 730. Therefore, in thisexample, the EMS 720 returns the device-based hybrid location, the usersubmitted home address, and the demographic data associated with theuser of the electronic device to the PSAP 730. The list of emergencycontacts and the medical history of the user are excluded from theresponse from the EMS 720.

Authentication

FIGS. 8A and 8B depict flow diagrams of an authentication process inaccordance with one embodiment. In some embodiments, as depicted in FIG.8A, an ESP personnel 865 logs into an ESP console 836 by providing theESP console 836 with log in credentials 881 a (e.g., a username andpassword, config file). In some embodiments, after the ESP personnellogs into the ESP console 836, the ESP console 836 automaticallytransmits log in credentials 881 b of the ESP personnel to a third-partynetwork 862. In this embodiment, the third-party network can thenidentify a role preassigned to the ESP personnel 865 (such as byrecognizing the log in credentials 881 b) and return a data packet 882for accessing the EMS 820. In some embodiments, the data packet 882includes credentials or access keys for accessing the EMS 820, calltypes for which to receive emergency data from the EMS 820, a datawindow URL to retrieve a webpage to display the enhanced data window (asdescribed below), and a session token URL to retrieve a session token.In some embodiments, the call types for which to retrieve emergency datafrom the EMS 820 include wireless voice calls, text calls, landlinecalls, and emergency callbacks.

In some embodiments, after the ESP console 836 receives the data packet882 from the third-party network 862, the ESP console 836 transmits thecredentials or access key for accessing the EMS 820, and an identifierof the role preassigned to the ESP personnel 865 to the EMS 820 usingthe session token URL received in the data packet 882 as anauthentication request 883 a. In some embodiments, the authenticationrequest 883 a is an HTTP POST request. For example, in some embodiments,the POST request includes an address of the EMS 820 server and a pointerto an authentication service in the form ofhttps://[EMS_Server]/[Authorization_Service] (e.g.,https://api.rapidsos.com/oauth/token, wherein [EMS_Server] (EMSServer)=api.rapidsos.com and [Authorization_Service] (AuthenticationService)=oauth/token). In some embodiments, the POST request includesthe following parameters:

client_id—unique identifier for the ESP of the ESP personnel 865

client_secret—password associated with the client_id

grant_type—role preassigned to the ESP personnel 865

In some embodiments, after receiving the authentication request 883 a,the EMS 820 then verifies or authenticates the credentials or access keyand the preassigned role and return an authentication response 884 aincluding a session token that can be used to access the emergency datastored within the EMS 820. For example, in some embodiments, theauthentication response 884 a returned from the EMS 820 is in a JSONform and includes the following information:

access_token—short-lived OAuth 2.0 session token (access token)

token_type—token type descriptor (e.g., “BearerToken”)

issued_at—UNIX timestamp in UTC of the time when the session token wasissued

expires_in—number of seconds after which the access token will expire(e.g., 3600 seconds)

In some embodiments, the session token expires (token expiry 885) at apredetermined amount of time (hereinafter, “expiry time”) elapsed fromthe time when the session token is issued. For example, in someembodiments, a session token expires after 3600 seconds. In someembodiments, the ESP console 836 automatically transmits a newauthentication request 883 b after two thirds of the expiry time haselapsed. After receiving the new authentication request 883 b, the ESP820 returns a new authentication response 884 b to the ESP console 836.In some embodiments, a session token will continue to be used until anew session token is received by the ESP console 836. In someembodiments, a session token is used until the session token expires.

In some embodiments, as depicted in FIG. 8B, after the ESP personnel 865logs into the ESP console 836 (such as by submitting log in credentials881 a), the ESP console 836 can transmit an authentication request 883 ato the EMS 820 without first communicating with a third-party network.The EMS 820 can then verify the authentication request 883 a anddetermine a role assigned to the ESP personnel 865 within the managementportal without communicating with a third-party network 862. The EMS 820can then return an authentication response 884 a. In some embodiments,as described above, the session token included in the authenticationresponse 884 a expires (token expiry 885) after a predetermined amountof time has elapsed from the time that the token is issued. The ESPconsole 836 can then transmit a new authentication request 883 b to theEMS 820, which in turn returns a new authentication response 884 b.

In some embodiments, access keys are activated by completing duediligence by phone, email or mail verification. In some embodiments,access keys expire and must be renewed. In some embodiments, access israte limited to a certain number of queries in a specified time limit(e.g., 1000 requests per minute) and monitored for abuse. In someembodiments, if a request with inactive or expired credentials isreceived, access is denied and an error is generated. In someembodiments, if an account or site has been compromised, the associatedaccess keys are temporarily or permanently disabled. In someembodiments, access keys or credentials allow for differential access todifferent requesting parties, as described below.

In some embodiments, as mentioned above, the management portal and theenhanced data display are included in a standalone web application(e.g., an emergency response application). In some embodiments, asdepicted by FIG. 8C, when an ESP personnel 865 logs into the standaloneweb application (such as by submitting a valid log in credentials 881 a)at the ESP console 836, the management portal identifies a roleassociated with the ESP personnel 865 and the emergency data fields oremergency data categories selected to be made accessible for the role.The management portal then returns one or more indicators 893 (e.g.,tags) of the emergency data fields or emergency data categories selectedto be made accessible for the role to the standalone web application.After the ESP personnel 865 logs into the web application at the ESPconsole 836, the ESP console 836 also sends an authentication request883 a to the EMS 820 and receives an authentication response 884 a fromthe EMS 820, as described above. In some embodiments, as describedabove, the session token included in the authentication response 884 aexpires (token expiry 885) after a predetermined amount of time haselapsed from the time that the token is issued. The ESP console 836 canthen transmit a new authentication request 883 b to the EMS 820, whichin turn returns a new authentication response 884 b.

Authentication, Credentials & Roles

To ensure the security, privacy and integrity of the data provided tothe ESP, proper authentication may be required at various steps. Theauthorization process may require the ESP member or user of the enhanceddata display (shown in FIGS. 10A-B, 11A-C) to verify their identitythrough the use of credentials such as log-in password, config file(e.g., a configuration created in a third-party system), etc. In someembodiments, the ESP member provides fingerprint, voice command, etc. tolog-in, which can be verified.

Various types of credentials may be utilized as a part of theauthentication process. Credentials may be generated, stored, verifiedand validated by the EMS. In some embodiments, the credentials aregenerated, and must be verified (e.g., phone verification) before use.In some embodiments, the credentials are valid for a specific durationof time (e.g., 1 minute, 5 minutes, 1 hour, 24 hours, etc.). Somecredentials are access keys, admin credentials, time-limited tokens,etc. In some embodiments, credentials are transmitted through securepathways (e.g., using encryption).

In some embodiments, credentials are used in a two-step authenticationprocess. As an example, the authentication requires: (i) a log-in andpassword for the ESP member to log-in the ESP system (e.g., FIG. 8A) and(ii) a time-limited access token to be generated based on anauthentication request. In some embodiments, a role (as described above)may be combined with the credentials and access token to create athree-step authentication process. For example, an administrator of theESP could have designated roles for various ESP members and selectedspecific emergency data fields to be made accessible for each role.

In contrast to system-generated credentials which must be created,stored and managed in specific ways, roles can be assigned by the adminto each member of the ESP. Examples of roles include admin, agent, calltaker, supervisor, manager, and other ESP personnel. In contrast tocredentials, roles do not need to be verified by system as they areusually admin-defined. In addition, the admin can update the role of anESP member to accurately reflect changes in jobs, positions andresponsibilities. In this way, the use of the roles allows the admin tocustomize the management portal to reflect the organizations under theirsupervision. In some embodiments, an ESP member has multipleadmin-defined roles. In some embodiments, default roles are provided bythe management portal for ESP administrators to choose between for amember of an ESP under the authority of the ESP administrator. Forexample, in some embodiments, the management portal provides two defaultroles, an admin role and an agent (or staff) role. The default roleshave different pre-assigned sets of emergency data fields and emergencydata categories to be made accessible for specific roles.

In some embodiments, the authentication of the data request is carriedout through the use of a credential, which is included in the datarequest (e.g., in the header of the request). When the emergencyclearinghouse receives the request, the credential (e.g., a token) isverified to ensure that it is valid and has not expired. In someembodiments, the data request also includes an identifier for theadmin-defined role for the ESP member. In some embodiments, the datarequest also includes the emergency data fields or emergency datacategories, or indicators (e.g., tags) of the emergency data fields oremergency data categories, that are accessible for the requesting party.In some embodiments, the data request includes the account name ororganization name, which may be used to pull up the associated geofenceof the requesting party.

Due to the diversity of ESP members (e.g., call dispatcher, PSAPmanager, police, paramedic) and the need for accurate and relevant data,there are specific challenges for emergency response. Althoughsystem-defined credentials may also be used to restrict access toemergency data, admin-defined roles were incorporated to allow thecustomization needed for different ESP members. In this way, the presentsystem allows for both secure authentication and significantcustomizations for managing access to emergency data for various membersof the organization.

With technological advances, the amount and types of data generatedabout emergencies have exploded, e.g., sensor data, Tot data,environmental data, health data, etc. Some of the data may be socritical, it should be always accessible to emergency personnel.Although it is obvious to make all available data to be made accessible,some of the data may be redundant or distracting and may hamperemergency response. As a result, it is important for each ESPorganization with diverse roles and organization structures, to be ableto manage data access to ESP users.

Emergency Data Retrieval

FIG. 9 depicts a flow diagram of an emergency data retrieval process inaccordance with one embodiment. In some embodiments, when an emergencyalert 967 is received by the ESP (e.g., when a PSAP receives a 911call), the emergency alert 967 is presented to the ESP console 936. Insome embodiments, the ESP console 936 verifies the call type (e.g.,wireless voice call, text call, landline call, or emergency callback).After receiving the emergency alert 967, an ESP personnel handling theemergency request (e.g., logged into the ESP console 936 that receivedthe emergency alert 967) requests emergency data associated with theemergency alert 967 from the EMS 920, as described above. For example,in some embodiments, the ESP personnel select a Request Emergency Databutton at the ESP console 936. In response to the selection of theRequest Emergency Data button, the ESP console 936 transmits anemergency data request 987 to the EMS 920. In some embodiments, theemergency data request 987 is automatically sent to the EMS 920 from theESP console 936 in response to receiving or detecting the emergencyalert 967. In some embodiments, the emergency data request 987 is anHTTP GET request, as described above. In some embodiments, as describedabove, the emergency data request 987 includes an identifier associatedwith the emergency alert 967. For example, in some embodiments, theemergency alert 967 is a 9-1-1 call made by a cell phone and theidentifier associated with the emergency alert is the phone number ofthe cell phone. In some embodiments, the emergency data request 987 issent using a data window URL received from a third-party network, asdescribed above. In some embodiments, the data window URL includes anaddress of the EMS server and an identifier of the emergency alert 967in the form of https://[EMS_Server]?[Alert_ID] (e.g.,https://api.rapidsos.com?caller_id={0}, wherein [EMS_Server] (EMSServer)=api.rapidsos.com and [Alert_ID] (emergency alertidentifier)=caller_id={0}). In some embodiments, the identifier of theemergency alert 967 includes an 11-digit phone number (also referred toas a CPN) (e.g., caller_id=72743767911, wherein 72743767911 is the phonenumber associated with the emergency alert 967). In some embodiments,the data window URL additionally includes the session token.

In some embodiments, the emergency data request 987 is an HTTP requestthat includes the following parameters or information in the header ofthe request:

Authorization—a session token (e.g., an access token)

X-RapidSOS-Role—the role assigned to the requesting ESP personnel withinthe management portal

In some embodiments, after receiving an emergency data request from theESP console 936, the EMS 920 verifies the session token and roleincluded in the emergency data request. After successfully verifying thesession token and role included in the emergency data request, the EMS920 gathers any and all emergency data associated with the emergencyalert 967 (e.g., emergency data tagged with the same phone number oremail associated with the emergency alert 967), as described above. Insome embodiments, after gathering emergency data associated with theemergency alert, the EMS 920 returns to the ESP console 936 only theemergency data 988 associated with the emergency alert 967 available foremergency data fields selected at the management portal to be madeaccessible for the role of the requesting ESP personnel, as describedabove. In some embodiments, the EMS 920 returns to the ESP console 936only the emergency data associated with the emergency alert 967available for the emergency data fields selected at the managementportal to be made accessible for the requesting ESP, as described above.In some embodiments, the EMS 920 returns all of the available emergencydata associated with the emergency alert 967 to the ESP console 936. Insome embodiments, before gathering emergency data associated with theemergency alert 967, the EMS 920 verifies that the call type is a calltype supported by the EMS 920 or the ESP console 936. In someembodiments, the EMS 920 only returns emergency data to the ESP console936 during the duration of an emergency session 989 associated with anemergency alert. In some embodiments, the EMS 920 only returns emergencydata to the ESP console 936 after the ESP has received data from an ALIdatabase 986.

In some embodiments, after authenticating an ESP or ESP personnel, theEMS 920 automatically returns appropriate emergency data to the ESPconsole 936 in response to detecting an emergency alert 967 presented tothe ESP console 936, without receiving an emergency data request fromthe ESP or ESP personnel. In some embodiments, the EMS 920 additionallyautomatically provides a new or updated return of appropriate emergencydata to the ESP console 936. In some embodiments, the EMS 920 provides anew or updated return of appropriate emergency data to the ESP console936 in real-time when new or updated emergency data associated with theemergency alert 967 is received by the EMS 920. In some embodiments, theEMS 920 provides a new or updated return of appropriate emergency datato the ESP console 936 according to a predetermined time interval.

In some embodiments, a system for managing access to emergency data foremergency service providers comprises: a) a management portalimplemented as one or more software modules on a computing systemcomprising a processor and a non-transitory computer readable storagemedium and configured to: i) establish a first role that can be selectedfor one or more users within an ESP; and ii) define a first set ofemergency data fields to be made accessible for the first role from aplurality of emergency data fields; b) an emergency response applicationimplemented as one or more software modules on a computing systemcomprising a processor, a display, and a non-transitory computerreadable storage medium and configured to: i) allow an ESP user to loginto the emergency response application, wherein the ESP user isassociated with the first role; ii) generate an emergency data requestcomprising an identifier associated with an emergency alert; and iii)transmit the emergency data request to an emergency management system;and c) the emergency management system, implemented as one or moresoftware modules on a cloud computing system comprising a processor anda non-transitory computer readable storage medium and configured to: i)receive the emergency data request from the emergency responseapplication; ii) gather, using the identifier associated with theemergency alert, emergency data associated with the emergency alertavailable for the first set of emergency data fields made accessible forthe first role; and iii) securely transmit the emergency data associatedwith the emergency alert available for the first set of emergency datafields made accessible for the first role to the emergency responseapplication for display on of the computing system. In some embodiments,the management portal is further configured to: a) establish a secondrole that can be selected for one or more users within the ESP; and b)define a second set of emergency data fields to be made accessible forthe second role from the plurality of emergency data fields, wherein thefirst set of emergency data fields and the second set of emergency datafields comprise different sets of emergency data fields. In someembodiments, defining the first set of emergency data fields comprisesdefining one or more emergency data categories, wherein each emergencydata category comprises at least one emergency data field. In someembodiments, the emergency data request comprises one or more tagsindicative of the set of emergency data categories to be made accessiblefor the first role; and the emergency management system is furtherconfigured to determine the set of emergency data categories to be madeaccessible for the first role using the one or more tags. In someembodiments, the emergency response application is further configured todetect the emergency alert when the emergency alert is received by theESP and autonomously generate the emergency data request in response todetecting the emergency alert. In some embodiments, the emergencyresponse application is further configured to generate the emergencydata request in response to user input at the emergency responseapplication. In some embodiments, the management portal furthercomprises a graphical user interface displayed at a display of thecomputing system on which the management portal is implemented andwherein the management portal is further configured to: a) display theplurality of emergency data fields on the display; and b) receive choiceof the set of emergency data fields from the plurality of emergency datafields by an administrator of the ESP through the graphical userinterface. In some embodiments, the emergency data request comprises oneor more tags indicative of the set of emergency data fields to be madeaccessible for the first role; and the emergency management system isfurther configured to determine the set of emergency data fields to bemade accessible for the first role using the one or more tags. In someembodiments, the emergency data request comprises an identifier of thefirst role; and the emergency management system is further configured todetermine the set of emergency data fields to be made accessible for thefirst role by querying the management portal using the identifier of thefirst role. In some embodiments, the emergency response application isfurther configured to detect the emergency alert, wherein the emergencyalert is generated by an electronic device and wherein the identifierassociated with the emergency alert is a phone number associated withthe electronic device. In some embodiments, the emergency alert is anemergency all made to the ESP by the electronic device. In someembodiments, the set of emergency data fields to be made accessible forthe role comprises location data and wherein the emergency dataassociated with the emergency alert comprises a location. In someembodiments, the emergency management system is further configured to:a) obtain a location associated with the emergency alert; b) access ageofence associated with the ESP; and c) determine if the location fallswithin the geofence associated with the ESP. In some embodiments, theemergency management system further comprises a software moduleconfigured to ingest data from at least one electronic device associatedwith the emergency alert.

In some embodiments, a system for managing access to emergency data foremergency service providers comprises: a) a management portalimplemented as one or more software modules on a computing systemcomprising a processor and a non-transitory computer readable storagemedium and configured to: i) establish a first role that can be selectedfor one or more users within an ESP; and ii) define a first set ofemergency data fields to be made accessible for the first role from aplurality of emergency data fields; and b) an emergency responseapplication implemented as one or more software modules on a computingsystem comprising a processor, a display, and a non-transitory computerreadable storage medium and configured to: i) allow an ESP user to loginto the emergency response application, wherein the ESP user isassociated with the first role; ii) generate an emergency data requestcomprising an identifier associated with an emergency alert; iii)transmit the emergency data request to an emergency management system;iv) receive emergency data associated with the emergency alert availablefor the first set of emergency data fields made accessible for the firstrole from the emergency management system; and v) display the emergencydata on the computing system.

In some embodiments, a system for managing access to emergency data foremergency service providers comprises: a) a management portalimplemented as one or more software modules on a computing systemcomprising a processor and a non-transitory computer readable storagemedium and configured to: i) establish a first role that can be selectedfor one or more users within an ESP; and ii) define a first set ofemergency data fields to be made accessible for the first role from aplurality of emergency data fields; and b) the emergency managementsystem, implemented as one or more software modules on a cloud computingsystem comprising a processor and a non-transitory computer readablestorage medium and configured to: i) receive an emergency data requestcomprising an identifier associated with an emergency alert from anaccount of an ESP user associated with the first role at the ESP; ii)gather, using the identifier associated with the emergency alert,emergency data associated with the emergency alert available for thefirst set of emergency data fields made accessible for the first role;and iii) securely transmit the emergency data associated with theemergency alert available for the first set of emergency data fieldsmade accessible for the first role to the ESP for display at a computingsystem within the ESP.

In some embodiments, a method for managing access to emergency data byan emergency management system comprises: a) receiving selection of arole for an emergency service provider (ESP) user at a management portalby an admin user; b) displaying, within the management portal, a firstset of data fields comprising data fields for selection and deselection;c) receiving a second set of data fields to be made accessible for therole from the first set of data fields, wherein the second set of datafields is a subset of the first set of data fields; d) receiving anemergency data request comprising an identifier associated with anemergency alert, wherein the emergency data request is generated inresponse to a query by the ESP user; e) gathering emergency dataassociated with the emergency alert available for the second set of datacategories using the identifier associated with the emergency alert; andf) securely transmitting, to the ESP, the emergency data associated withthe emergency alert available for the second set of data categories inresponse to receiving the emergency data request, wherein the emergencydata associated with the emergency alert available for the second set ofdata categories is displayed at an electronic device associated with theESP user.

In some embodiments, a method for managing access to emergency data byan emergency management system comprises: a) displaying, within themanagement portal, a first set of data categories comprising datacategories for selection and deselection by an admin user of theemergency service provider; b) receiving a second set of data categoriesto be made accessible to a plurality of users of the ESP from the firstset of data categories, wherein the second set of data categories is asubset of the first set of data categories; c) receiving an emergencydata request comprising an identifier associated with an emergency alertfrom an ESP user; d) gathering emergency data associated with theemergency alert available for the second set of data categories usingthe identifier associated with the emergency alert; and e) securelytransmitting, to the ESP, the data associated with the emergency alertavailable for the second set of data categories in response to receivingthe emergency data request, wherein the data associated with theemergency alert available for the second set of data categories isdisplayed at an electronic device associated with the ESP user.

In some embodiments, a method for managing access to emergency data foremergency service providers by an emergency management system comprises:a) receiving at least one role from an emergency service provider (ESP)at a management portal; b) displaying, within the management portal, afirst set of data categories for selection or deselection; c) receivinga second set of data categories to be made accessible for the role formthe first set of data categories, wherein the second set of datacategories is a subset of the first set of data categories; d) detectingan emergency alert; e) autonomously generating an emergency data requestcomprising an identifier associated with the emergency alert; f)gathering emergency data associated with the emergency alert availablefor the second set of data categories using the identifier associatedwith the emergency alert; and g) securely transmitting, to the ESP, thedata associated with the emergency alert available for the second set ofdata categories in response to receiving the emergency data request,wherein the data associated with the emergency alert available for thesecond set of data categories is displayed at an electronic deviceassociated with the ESP for providing an emergency response.

Data Source Restrictions

In some embodiments, as described above, the ingestion modules 258 tagdata received by the clearinghouse 250 based on the data source (e.g.,device name or type, application name, user name, phone number,corporate account, etc.). In some embodiments, the EMS 920 restrictsemergency data returned to an ESP to a particular data source. Forexample, in some embodiments, the EMS 920 restricts emergency datareturned to an ESP to data received from the electronic device thatgenerated the associated emergency alert. In some embodiments, the EMS920 restricts data returned to an ESP to data generated by theelectronic device that generated the associated emergency alert 967. Insome embodiments, the EMS 920 restricts data returned to an ESP to datareceived from a mobile application from which the associated emergencyalert 967 was generated. However, the EMS 920 may also exclude datareturned to an ESP based on data source. Differentiating betweendifferent data sources may be useful as user consent, privacyconsiderations, trustworthiness, and usefulness of the data can varybetween sources can vary between sources.

For example, in some embodiments, the EMS 920 can exclude data from aparticular data source that would otherwise available for an emergencydata request. For example, in one embodiment, the EMS 920 tags data witha phone number as an identifier of a user associated with the phonenumber. In this example, John Doe is associated with the phone number(555) 555-555. John Doe has an Apple iPhone, an Apple Watch, and a ridesharing app (e.g., Uber or Lyft). Within the ride sharing app, John Doehas submitted his home address and work address as user submittedaddresses, which have been received by the EMS 920, tagged with theidentifier (555) 555-5555, and tagged with the data source “ride sharingapp.” In this example, if John Doe generates an emergency alert 967through the ride sharing app (e.g., by selecting a panic button in theapp if John Doe thinks his driver is endangering him), and an ESP sendsthe EMS 920 an emergency data request associated with (555) 555-5555,the EMS 920 can return the user submitted locations as well as locationsgenerated by or received from John Doe's iPhone or Apple Watch to theESP. However, in this example, if John Does generates an emergency alert967 by dialing 9-1-1, and an ESP sends the EMS 920 an emergency datarequest associated with (555) 555-5555, the EMS 920 can return only thelocations generated by or received from John Doe's iPhone and AppleWatch and exclude the user submitted locations because they werereceived by the EMS 920 from the ride sharing app.

Emergency Data Subscription

As described above, in some embodiments, an emergency management system(EMS) maintains a clearinghouse that obtains and shares emergency datato aid emergency service providers (ESPs) in responding to emergencies.During an emergency, an ESP can send an emergency data request to theEMS, and, in response, the EMS can send any available emergency dataassociated with the emergency to the requesting ESP. In someembodiments, as described above, the ESP includes an identifierassociated with an emergency alert in the emergency data request. TheEMS can then use the identifier associated with the emergency alert toretrieve emergency data associated with the emergency alert from theclearinghouse. For example, as described above, an ESP (e.g., a publicsafety answering point (PSAP)) can receive an emergency alert in theform of a 9-1-1 phone call (representative of an emergency or potentialemergency) from a mobile phone associated with a phone number (e.g.,(555) 555-5555)). The ESP can then send an emergency data requestincluding the phone number (i.e., the identifier of the emergency alert)to the EMS, which can then retrieve any emergency data within theclearinghouse associated with the phone number and return the availableemergency data to the requesting ESP. This process of returningemergency data to an ESP in response to an emergency data request isreferred to as “pulling” emergency data from the clearinghouse.

However, in some embodiments, the EMS can “push” emergency data from theclearinghouse to an ESP (i.e., the EMS can send emergency data to an ESPwithout receiving an emergency data request). In some embodiments, theEMS pushes emergency data to ESPs using an emergency data subscriptionsystem. Using the emergency data subscription, a recipient (or potentialrecipient) of emergency data from the clearinghouse can subscribe to theclearinghouse for a particular device identifier or user identifier(hereinafter, “subscription”). After subscribing to a subscription, therecipient (e.g., an ESP or an ESP personnel) may automatically receiveupdates regarding the subscription without first sending an emergencydata request. For example, in some embodiments, if an ESP subscribes toa phone number, whenever the clearinghouse receives updated emergencydata associated with the phone number, the clearinghouse canautomatically send the updated emergency data associated with the phonenumber to the ESP, without first receiving an emergency data requestincluding the phone number. For example, in some embodiments, if arecipient is subscribed to a particular phone number, and theclearinghouse receives a new or updated location associated with theparticular phone number, the clearinghouse will instantly andautomatically push the new or updated location associated with theparticular phone number to the recipient the moment that the new orupdated location is received by the clearinghouse, without the recipienthaving to send an emergency data request. In some embodiments, the EMSestablishes a websocket connection with an ESP in order to pushemergency data regarding a subscription to which the ESP is subscribedto the ESP. WebSocket is a type of computer communications protocol. Awebsocket connection is a longstanding internet connection between aclient and a server that allows for bidirectional communication betweenthe client and server without the client needing to send data requeststo the server, which differentiates the WebSocket computercommunications protocol from other types of computer communicationsprotocols such as the HyperTextual Transfer Protocol (HTTP). The WebSocket protocol is often used by chat clients to facilitate user to userwebchats. In some embodiments, the EMS establishes a websocketconnection with an ESP in response to receiving an emergency datarequest. In some embodiments, the EMS establishes a websocket connectionwith an ESP when an ESP personnel logs into an ESP console. In someembodiments, the EMS establishes a websocket connection with an ESP whenan ESP personnel logs into the emergency response application. In someembodiments a websocket connection established between the EMS and anESP is maintained by the EMS for the duration of the ESP personnel'slog-in session.

In some embodiments, the EMS automatically subscribes a recipient to asubscription (e.g., a particular device identifier or user identifier)in response to receiving an emergency data request including thesubscription or an identifier of the subscription. For example, in someembodiments, when an ESP personnel sends an emergency data requestincluding a phone number to the EMS through their ESP console, the EMSsubscribes the ESP personnel to the phone number and establishes awebsocket connection with the ESP console. Then, whenever theclearinghouse receives updated emergency data associated with the phonenumber, the EMS can automatically push the updated emergency dataassociated with the phone number to the ESP console. For example, an ESPpersonnel logs into an emergency response application in communicationwith the EMS on the ESP personnel's ESP console. Subsequently, the ESPpersonnel receives a 9-1-1 call from a mobile phone and then generatesand sends an emergency data request including the phone number of themobile phone to the EMS through the emergency response application. TheEMS then uses the phone number of the mobile phone to retrieve the mostrecent location associated with the mobile phone received by theclearinghouse and returns the most recent location associated with themobile phone to the ESP personnel through the emergency responseapplication. The EMS simultaneously subscribes the ESP personnel to thephone number of the mobile phone and establishes a websocket connectionbetween the EMS and the ESP console and automatically pushes any updatedemergency data (e.g., locations) associated with the phone numberreceived by the clearinghouse to the emergency response application assoon as the updated emergency data associated with the phone number isreceived by the clearinghouse.

Enhanced Data Display

FIGS. 10A and 10B illustrate embodiments of a tabular view of anenhanced data display in accordance with one embodiment. In someembodiments, the EMS returns the emergency data associated with theemergency alert by displaying the emergency data through the enhanceddata display, as depicted by FIGS. 10A and 10B. In some embodiments, asdepicted by FIGS. 10A and 10B, the enhanced data display 1064 isaccessed in an embedded window within an existing ESP system console UI1036, such as by selecting the enhanced data tab 1091. In someembodiments, the EMS only returns emergency data to an ESP console 1036if the Enhanced Data Display tab button 1091 is selected. In someembodiments, the enhanced data display 1064 displays locationinformation, as depicted by FIG. 10A, above additional data such asdemographic data and profile picture, as depicted by FIG. 10B. Theadditional data may be in various formats including text, images, video,weblinks, etc. In some embodiments, the enhanced data display 1064(including more accurate and comprehensive information) is displayedalongside basic data received from an ALI database 1086.

FIGS. 11A, 11B, and 11C illustrate embodiments of an enhanced datadisplay in accordance with one embodiment. In some embodiments, theenhanced data display 1164 is a standalone window, as depicted in FIG.11A, or a standalone application installed at the ESP system or console.In some embodiments, the enhanced data display 1164 displays emergencydata returned from the EMS within discrete categories of emergency data.For example, in some embodiments, as depicted by FIG. 11A, the enhanceddata display 1164 can separately display the “Demographics,” “ContactInformation,” and “Addresses” emergency data categories in individualsections. In some embodiments, the “Demographics,” “ContactInformation,” and “Addresses” emergency data categories (as describedabove) are displayed sequentially under a “Personal Information” (asdescribed above) section of the enhanced data window 1164. In someembodiments, a “Medical Information” (as described above) section isdisplayed below the “Personal Information” section. For some roles withrestricted access to medical data, the medical data is not displayed inthis view. In some embodiments, the enhanced data display 1164 includesone or more tabs 1192 to filter emergency data categories. For example,as depicted in FIG. 11A, the enhanced data display 1164 can include a“Caller Information” tab, a “Location” tag, a “Caller-ProvidedLocations” tab, a “Devices” tab, and a “Directions” tab. In someembodiments, a “Directions” tab can be selected within the enhanced datadisplay 1164 to render a map displaying directions from an ESP to alocation of an emergency situation. In some embodiments, the map iscapable of providing real-time or near real-time traffic updates.

In some embodiments, the enhanced data display (as shown in FIGS. 10A-B,11A-C) includes one or more tabs such as a “location” tab, in which datapertaining to a specific topic (e.g., a particular emergency datacategory) is consolidated. In some embodiments, the data pertaining tolocation are marked or tagged as “location data” or saved as a part ofan emergency data category or supergroup of emergency data categories inthe clearinghouse 250 (see FIG. 2), as described in reference to FIG.5B. In some embodiments, the data fields marked with a specific tag suchas “location data” are selected by the administrator of the ESP, whichoptionally include one or more data fields pertaining to location. Thus,with one selection, the administrator allows access to several pieces ofinformation that can be helpful for the emergency response.

An example of a list of data fields, which will be displayed in thelocation tab, include caller_id, location time, latitude, longitude,uncertainty_radius, etc. In some embodiments, location-related data isincluded in the ingestion data, and are optionally hardwired not to bedisplayed as a data field for selection. A list of data fields caninclude: format_version (version of LEI format the data was rendered);created_time (UNIX timestamp in UTC of when the location record wascreated); call_start_time (UNIX timestamp in UTC of when the emergencycall began); source (input source that created the location record,e.g., Haven); etc. In other embodiments, the preceding data fields areincluded as an anchor data field (an emergency data field that cannot beunselected, as described above) or a selectable data field.

In some embodiments, the enhanced data display includes a “callerinformation” tab or group, in which personal information about thecaller is consolidated. Examples of “Caller Information” data isdepicted in Table 2.

In some embodiments, the enhanced data display (as shown in FIGS. 10A-B,11A-C) includes a “device data” tab or group, in which data pertainingto one or more devices associated with a user is consolidated. In someembodiments, several devices of the user may be consolidated in one tab.In some embodiments, each device may have a dedicated section (e.g., asub-tab). It is contemplated that device data may not be available inmany cases.

In some embodiments, device data associated with one or more devicesassociated with a user (or a close loved one) is displayed if it isavailable. If such data is unavailable, the data categories will becollapsed in the enhanced data display. It is contemplated that thelayout of the display may depend on the type of device, the type ofdata, the type of emergency, the priority or severity of the emergency,the likelihood that the information will be useful for the emergencyresponse, etc. Examples of device data is depicted shown in Table 3.

In some embodiments, the enhanced data display (as shown in FIGS. 10A-B,11A-C) includes a “caller-provided locations” tab or group, in whichdata pertaining to one or more locations provided by the user isconsolidated. It is contemplated that caller-provided location may notbe available in many cases. The caller-provided location is understoodbe different from the data in the “location” tab or group, which is thecurrent location of the user. The data in the location tab or group maybe validated and the likely or probable location of the user. Examplesof caller-provided location data is depicted shown in Table 4.

In some embodiments, the enhanced data display (as shown in FIGS. 10A-B,11A-C) includes a “service information” tab or group, in which datapertaining to one or more data providers are consolidated. It iscontemplated that caller-provided location may not be available in manycases. Examples of service data fields include contact_url,data_provider_contact_address, data_provider_contact_phone,data_provider_contact_phone, data_provider_url, provider_id,service_environment, service_mobility, service_type, type_of_provider,etc.

Dynamic Visualization

In some embodiments, as depicted by FIGS. 11B and 11C, the EMS appliesdynamic visualization elements to the emergency data displayed throughthe enhanced data display 1164. In some embodiments, the dynamicvisualization elements include displaying content sequentially, movingcontent, separating content, etc. In some embodiments, the dynamicvisualization elements include changing font type, font size, font face,font color or using highlighting, backgrounds, sounds icons, animationsor images to emphasize or deemphasize content.

For example, in some embodiments, the EMS selectively emphasizes singleemergency data fields or groups of emergency data fields. As an example,as depicted in FIG. 11B, the EMS emphasizes all of the emergency datafields within the “Demographics” emergency data category by enlargingand bolding the included emergency data fields. In another example, asdepicted by FIG. 11C, the EMS emphasizes all of the emergency categorieswithin the “Contact Information” emergency data category, by onlybolding the included emergency data fields. In some embodiments, the EMSemphasizes an emergency data field by highlighting, bolding, enlarging,underlining, moving, or coloring the data field. In some embodiments,the EMS emphasizes an emergency data field using an animation such as bycausing the data field to appear, fade in and out, fly or float in,flash, pulsate, rotate, translate (e.g., move laterally or vertically),change in size, grow and turn, change colors, wave, or bounce. It iscontemplated that specific emergency data fields can be emphasized ordeemphasized by various tools such as font type, font size, font face,font color, highlighting, background color or pattern, icons, or otherways. In some embodiments, one or more data fields are emphasized whileothers are de-emphasized to further draw attention to the emphasizeddata. In some embodiments, the rule set is customized by anadministrator and/or ESP personnel.

Dynamic visualization can be useful for emphasizing specific data fieldswhen those data fields are most likely to be helpful to ESP personnel inresponding to an emergency situation. In some embodiments, dynamicvisualization is carried out according to a dynamic visualization schemesuch as a set of one or more rules that determine when certain datafields are to be emphasized and how they are to be emphasized. In someembodiments, the EMS applies dynamic visualization to various emergencydata fields or different groups of emergency data fields at differenttimes. For example, in some embodiments, the EMS applies a dynamicvisualization element to different groups of emergency data fieldssequentially. For example, in some embodiments, the EMS first bolds allof the emergency data fields within the “Demographics” emergency datacategory (as depicted in FIG. 11B) and then sequentially bolds all ofthe emergency data fields within the “Contact Information” emergencydata category (as depicted in FIG. 11C) while returning the emergencydata fields within the “Demographics” emergency data category to theirdefault or previous visualization. In some embodiments, the EMSsequentially applies dynamic visualizations to different emergency datafields or different groups of emergency data fields according to apredetermined timing schedule or rule set. For example, in oneembodiment, upon transmitting emergency data to an ESP and displayingthe emergency data through the enhanced data display 1164 (time (t)since displaying the emergency data=0 seconds (s)), the EMS bolds andenlarges the “name” emergency data field after two seconds (e.g., t=2s), returns the “name” data field to its default visualization, boldsand enlarges the “languages” data field at t=5 s, returns the“languages” data field to its default visualization, bolds and enlargesthe “gender” data field at t=8 s, and finally returns the “gender” datafield to its default visualization at t=10 s. Alternatively, as anotherexample, the EMS bolds and enlarges both the “name” and “languages” datafields at t=2 s, and returns the “name” and “languages” data fields totheir default visualizations while bolding and enlarging the “gender”data field at t=5 s. In some embodiments, the EMS sequentially appliesdynamic visualizations to different emergency data fields at differenttimes according to any schedule or visualization scheme.

In some embodiments, the EMS applies dynamic visualization to anemergency data field or group of emergency data fields in response touser input at an ESP. For example, in some embodiments, after sending anemergency data request to the EMS and receiving emergency data from theEMS through the enhanced data display 1164 at an ESP console, an ESPpersonnel (e.g., a PSAP call taker) selects a soft or hard button (e.g.,press a key on their keyboard) to apply dynamic visualization to one ormore emergency data fields. For example, in some embodiments, the EMScan sequentially apply dynamic visualizations to one or more emergencydata fields according to a predetermined order. In some embodiments, theESP personnel can step through the predetermined order using the arrowkeys on their keyboard. For example, when the ESP personnel presses theright arrow, the EMS applies a dynamic visualization to the nextemergency data fields or group of emergency data fields according to thepredetermined order; if the ESP personnel presses the left arrow, theEMS can apply a dynamic visualization to the previous emergency datafield or group of emergency data fields according to the predeterminedorder. Alternatively, for example, a specific key on the ESP personnel'skeyboard is associated with applying a dynamic visualization to aspecific emergency data field or group of emergency data fields. Forexample, in some embodiments, if the ESP personnel presses the ‘M’ keyon their keyboard, the EMS applies one or more dynamic visualizationelements to the one or more of the emergency data fields included in the“Medical Information” emergency data category.

In some embodiments, the EMS can apply dynamic visualization to anemergency data field or group of emergency data fields in response tocontextual cues detected during an emergency session (e.g., during a9-1-1 phone call between a 9-1-1 caller and a PSAP call taker). Forexample, during a 9-1-1 call, if the EMS detects the word ‘name’ spokenaloud (e.g., a PSAP call taker asks a 9-1-1 caller for their name), theEMS can automatically apply a dynamic visualization to the “name” datafield. Or for example, during a 9-1-1, if the EMS detects the word‘location’ spoken aloud (e.g., a PSAP call taker asks a 9-1-1 caller fortheir location), the EMS can automatically apply a dynamic visualizationto the “addresses” group of emergency data fields.

In some embodiments, the PSAP call taker may request specific type ofdata (e.g., by pressing a soft button), which may be displayed withdynamic visualization elements. For example, if the call taker indicatesthat it is a medical emergency, the medical data may be emphasized bythe use of one or more dynamic visualization elements. In someembodiments, the dynamic visualization may in the form of a feedbackflow, where the PSAP may be prompted to provide feedback in a logicalsequence. For example, after the PSAP call taker has selected a medicalemergency, she may be prompted to select a type from a list (e.g.,injury, chronic illness, unconscious, unknown, etc.) and specificmedical data may be displayed and/or emphasized. If chronic illness ischosen, the user's available illnesses are displayed and/or emphasized.If injury is chosen, the location of the injury may be provided,previous injuries in the patient's medical history may be displayedand/or emphasized.

FIG. 12 depicts an embodiment of a graphical user interface provided byan emergency response application in accordance with one embodiment. Insome embodiments, FIG. 12 depicts an enhanced data display or dashboardprovided by the emergency response application. The dashboard is a pagewithin the GUI that provides interactive elements that allow a user togenerate an emergency data request using the emergency responseapplication. For example, in some embodiments, the dashboard includes anentry field 1287A through which a user can submit a device identifier,such as by typing or pasting the device identifier into the entry field1287A. In some embodiments, after submitting a device identifier throughthe entry field 1287A, the user can prompt the emergency responseapplication to generate and send an emergency data request by selectinga search button 1287B. In some embodiments, in response to a usersubmitting a device identifier into the entry field 1287A and selectingthe search button 1287B, the emergency response application generates anemergency data request including the device identifier and a temporaryaccess token to the clearinghouse, as described above. In someembodiments, the emergency response application automatically generatesan emergency data request (e.g., without a user manually submitting adevice identifier) in response to detecting an emergency alert, asdescribed above.

In some embodiments, after receiving an emergency data request includinga device identifier, the clearinghouse retrieves or gathers emergencydata associated with the device identifier from one or moreclearinghouse databases, as described above. In some embodiments, theemergency data associated with the device identifier includes one ormore locations. In some embodiments, the emergency data associated withthe device identifier includes a current location. In some embodiments,the emergency data associated with the device identifier includes one ormore historical locations. In some embodiments, the clearinghousedetermines which types of emergency data (e.g., emergency data fields oremergency data categories) that the requesting user is allowed toreceive based on a role associated with the requesting user, asdescribed above. In some embodiments, after retrieving or gathering theemergency data, the clearinghouse returns the emergency data to theemergency response application. The emergency response application canthen display the emergency data within the GUI. In some embodiments, theemergency response application displays the emergency data within thedashboard, as depicted in FIG. 12. For example, in some embodiments, theemergency response application displays a graphical indicator of acurrent location 1289A returned from the clearinghouse within a map 1288provided by the GUI. In some embodiments, the emergency responseapplication displays a textual description of a current location 1289Bwithin the GUI. In some embodiments, the emergency response applicationdisplays textual descriptions of one or more historical locations withinthe GUI 1289C. In some embodiments, the textual description of a currentor historical location includes a time and date, an estimated address,altitude, latitude and longitude, and an uncertainty radius. In someembodiments, the textual description of a current or historical locationincludes an indoor location. In some embodiments, the textualdescription of a current or historical location additionally includes anamount of time elapsed since the current or historical location wasreceived. In some embodiments, the textual description of a current orhistorical location additionally includes an amount of time elapsedsince the current or historical location was generated.

Emergency Data Geofencing

FIG. 13A depicts a diagram of a geofence applied to a clearinghouse foremergency data in accordance with one embodiment. As described above, insome embodiments, an administrator of an ESP is required to submit ageospatial representation (e.g., a geofence) of a region that the ESPserves. In some embodiments, the geofence bounds an authoritativejurisdiction, which is mandated by a higher authority (e.g., a PSAPjurisdiction). In some embodiments, the geofence bounds anadministrative region (e.g., state highway troopers may serve areas nearhighways). In some embodiments, the geofence bounds an assignedjurisdiction (e.g., a police patrol). In some embodiments, the ESP maybe a private police service, such as university campus and thejurisdiction are areas owned by the university.

In some embodiments, a geofence module 1370 is applied to theclearinghouse 1350 to protect potentially sensitive emergency data usinggeospatial analysis. In some embodiments, as described above withrespect to FIG. 2, the clearinghouse 1350 includes a set of ingestionmodules 1358 and a set of retrieval modules 1359. The set of ingestionmodules can receive emergency data, or other information that can beuseful in responding to an emergency, from a variety of sources. Forexample, in some embodiments, a smartphone sends emergency data to theclearinghouse 1350 in the form of an HTTP POST API call in response to auser of the smartphone initiating a 911 emergency call. As depicted inFIG. 13A, in some embodiments, when emergency data (e.g., an emergencylocation or additional emergency data) is sent from an electronic device1310 to the clearinghouse 1350, the emergency data is first processed bya geofence module 1370 before being received by the set of ingestionmodules 1358 within the clearinghouse 1350, as described below withrespect to FIG. 13B. Similarly, in some embodiments, when an emergencydata request is sent from a requesting party (e.g., an ESP), theemergency data request is processed by the geofence module 1370 beforebeing received by the set of retrieval modules 1359 for display on at acomputing device of the requesting party.

In some embodiments, as mentioned above, a geofence module is applied tothe clearinghouse to protect potentially sensitive emergency data usinggeofences. Generally, a geofence is a virtual perimeter for a real-worldgeographic area. A geofence can be dynamically generated—as in a radiusaround a point location—or a geofence can be a predefined set ofboundaries (such as school zones or neighborhood boundaries). The use ofa geofence is called geofencing, and one example of usage involves alocation-aware device of a location-based service (LBS) user entering orexiting a geofence. Entry or exit from a geofence could trigger an alertto the device's user as well as messaging to the geofence operator. Thegeofence information, which could contain the location of the device,could be sent to a mobile telephone or an email account.

For emergency response, an emergency service provider (public or privateentities) may be given jurisdictional authority to a certaingeographical region or jurisdiction (also referred to as “authoritativeregions”). In the context of emergency services, one or more geofencesmay correspond to the authoritative region of an ESP. In many cases, theESP is a public entity such as a public safety answering point (PSAP) ora public safety service (PSS; e.g., a police department, a firedepartment, a federal disaster management agency, national highwaypolice, etc.), which have jurisdiction over a designated area(sometimes, overlapping areas). Geofences are used to define thejurisdictional authority by various methods and in various GeographicInformation System (GIS) formats. In some embodiments, geofences onlyrepresent authoritative regions if the geofence has been assigned orverified by a local, state, or federal government. In some embodiments,geofences represent assigned jurisdictions that are not necessarilyauthoritative regions. For example, in some embodiments, a geofence isunilaterally created by its associated ESP without verification orassignment by a local, state, or federal government.

Geofences can be defined in various ways. For example, in someembodiments, a geofence comprises one or more of the following: a countyboundary, a state boundary, a collection of postal/zip codes, acollection of cell sectors, simple shapes, complex polygons, or othershapes or areas. In some embodiments, geofences comprise approximationswhere the “approximated” geofence encloses an approximation of theauthoritative region.

Updates to geofences may be required over time because the authoritativeregions may change over time. Geofences may change over time (e.g., anew sub-division has cropped up) and require updates. In someembodiments, the systems and methods described herein allow geofences tobe updated (e.g., a PSAP administrator can upload updated geofence GISshapefiles).

For maintaining the privacy, security and integrity of the data,geofencing may be applied to emergency data. For example, applyinggeofence filters to the emergency data allows additional avenues formonitoring, both visibility and control, over the clearinghouse todetect anomalies/spikes and reduce the risk of security breaches.

FIG. 13B depicts a diagram of ingestion and retrieval geofences appliedto an emergency data clearinghouse in accordance with one embodiment. Insome embodiments, the emergency data is obtained from device 1310 (alsoreferred to as an “upstream data producing device”). On the retrievalside, an ESP accesses the clearinghouse 1350 by sending an emergencydata request, through the ESP integration system 1360, to theclearinghouse 1350, as described above. An ingestion geofence 1374 (alsoreferred to as “upstream filtering”) is applied to restrict sending ofdata from devices 1310 to the clearinghouse 1350 from geographical areasthat are not covered by the “combined authoritative jurisdiction” (i.e.,covered one or more provisioned geofences in the geofence database (notshown)). In some embodiments, the ingestion geofence (also referred toas an “ingress filter”) is applied to the ingestion module 1358 toprotect against accidental breaches of privacy. In some embodiments, theingestion module 1358 of the clearinghouse 1350 drops location payloadsthat do fall within the geographical region covered by the “combinedauthoritative region.”

In some embodiments, the clearinghouse 1350 comprises one or moredatabases 1357 (e.g., a database storing emergency data). For example,in some embodiments, the retrieval module obtains emergency data from aclearinghouse 1350 database 1357 to send to an ESP in response to anemergency data request, as described above. In some embodiments, theretrieval geofence 1372 (also referred to as an “egress filter”) isapplied at the retrieval module 1359 of the clearinghouse 1350. Applyinggeofencing to retrieved emergency data will protect against abuse andlimit the scope of security breaches in cases where credentials havebeen compromised. In some embodiments, one or more geofences areassociated with one or more credentials associated with an ESP agency ororganization. In some embodiments, the credentials associated with anESP agency or organization confers authorization to access data such asemergency data from the clearinghouse. In some embodiments, specificauthorization to access data is granted individually to members of aPSAP through tokens derived from the credentials for that PSAP.

In some embodiments, when the retrieval module 1359 checks thecoordinates of current location data (within retrieved emergency data)associated with a device identifier with the geofence(s) associated withthe credentials in an emergency data request. If the current location iswithin the geofence region (enclosed by the geofence(s)), the currentlocation is returned to the ESP and displayed within the ESP console. Ifnot, the module 1359 will return a “not found” message (as opposed tothe retrieved location is outside the geofence) to protect privacy.

In some embodiments, geofences can be used for reporting results forinternal metrics and monitoring the system. For example, the number ofemergency data requests, locations provided, “no location found” etc.,can be obtained for a geofence(s) associated with a PSAP. Using singleor combined geofences, the emergency data can be obtained oncounty-wide, city-wide, postal code, course grid (rectangle overlay),state-wide, or country-wide basis. In some embodiments, ingress andegress counters (i.e., percent of emergency sessions where the locationdata was received, but not queried) and other similar metrics can becalculated and analyzed to identify problems and spikes. In someembodiments, different geofences are used for retrieval and forreporting.

In some embodiments, a buffer (e.g., +10 km) is added to the geofence(s)so that results within the buffer zone are also returned. In many cases,PSAPs have discretion and incentive to respond to emergencies that arebeyond their authoritative jurisdiction. As an example, a geofence thatis a circular area with a radius of 10 km would have an area of 100π or˜314 km2, whereas the same area with a 10 km buffer around itscircumference would have yield a combined radius of 20 km and a combinedarea of 400π or 1256 km2. In some embodiments, the buffer is from 0.5 kmto 5 km, from 0.5 km to 10 km, from 0.5 km to 15 km, from 0.5 km to 20km, from 0.5 km to 25 km, or from 0.5 km to 30 km. In some embodiments,the buffer is from 1 km to 5 km, from 1 km to 10 km, from 1 km to 15 km,from 1 km to 20 km, or from 1 km to 30 km. In some embodiments, thebuffer is at least 0.1 km, at least 0.2 km, at least 0.3 km, at least0.4 km, at least 0.5 km, at least 0.6 km, at least 0.7 km, at least 0.8km, at least 0.9 km, at least 1 km, at least 2 km, at least 3 km, atleast 4 km, at least 5 km, at least 6 km, at least 7 km, at least 8 km,at least 9 km, at least 10 km, at least 11 km, at least 12 km, at least13 km, at least 14 km, at least 15 km, at least 16 km, at least 17 km,at least 18 km, at least 19 km, at least 20 km, at least 25 km, or atleast 30 km. In some embodiments, the buffer is no more than 0.1 km, nomore than 0.2 km, no more than 0.3 km, no more than 0.4 km, no more than0.5 km, no more than 0.6 km, no more than 0.7 km, no more than 0.8 km,no more than 0.9 km, no more than 1 km, no more than 2 km, no more than3 km, no more than 4 km, no more than 5 km, no more than 6 km, no morethan 7 km, no more than 8 km, no more than 9 km, no more than 10 km, nomore than 11 km, no more than 12 km, no more than 13 km, no more than 14km, no more than 15 km, no more than 16 km, no more than 17 km, no morethan 18 km, no more than 19 km, no more than 20 km, no more than 25 km,or no more than 30 km.

In some embodiments, a system for managing access to emergency data foremergency service providers comprises: a) a management portalimplemented as one or more software modules on a computing systemcomprising a processor and a non-transitory computer readable storagemedium and configured to: i) establish a first role that can be selectedfor one or more users within an ESP; and ii) define a first set ofemergency data fields to be made accessible for the first role from aplurality of emergency data fields; b) an emergency response applicationimplemented as one or more software modules on a computing systemcomprising a processor, a display, and a non-transitory computerreadable storage medium and configured to: i) allow an ESP user to loginto the emergency response application, wherein the ESP user isassociated with the first role; ii) generate an emergency data requestcomprising an identifier associated with an emergency alert; and iii)transmit the emergency data request to an emergency management system;and c) the emergency management system, implemented as one or moresoftware modules on a cloud computing system comprising a processor anda non-transitory computer readable storage medium and configured to: i)receive the emergency alert, wherein the emergency alert comprises alocation; ii) access a geofence associated with the ESP; iii) determineif the location falls within the geofence associated with the ESP; iv)receive the emergency data request from the emergency responseapplication; v) if the location is determined to fall within thegeofence associated with the ESP, gather, using the identifierassociated with the emergency alert, emergency data associated with theemergency alert available for the first set of emergency data fieldsmade accessible for the first role; and vi) securely transmit theemergency data associated with the emergency alert available for the setof emergency data fields made accessible for the first role to theemergency response application for display at the computing system.

FIG. 14 illustrates examples of geofence approximations that can besubmitted as an “authoritative jurisdiction” for a PSAP. One or moregeofences enclose the geofenced region which is under the authoritativejurisdiction of a PSAP. In some cases, the geofenced region is a complexpolygon, and is optionally approximated using an appropriate simplershape. For example, a rectangle (A), two disjointed rectangles (B, B′),a polygon with several sides (C) and a triangle (D), may representdifferent geofenced regions (defined by one or more geofences).

In some embodiments, an administrator of a PSAP submits the complexauthoritative jurisdiction as one or more approximate geofence(s) byspecifying points. For example, the PSAP administrator can submitgeofenced region A by specifying two points—the north-west corner andthe south-east corner using a drawing tool provided by the GUI of theemergency response application. In this example, the two points of thegeofenced region are set using two latitude-longitude coordinates. Inanother example, the multiple-sided polygon C is submitted by specifyingthe five corners. In some embodiments, a PSAP administrator approximatesa geofence for a PSAP by drawing one or more polygons using a drawingtool provided by the GUI of the emergency response application. In someembodiments, a geofence is generated using a series of points that areconnected (e.g., entering three longitude-latitude points on a map toform a triangular geofence).

Approximating a complex geofenced region has several advantages. Thegeofence(s) are simple and the calculations can be quicker and lesscumbersome for applications where exact calculations are not needed.

In some embodiments, a PSAP administrator can submit a GIS file (e.g., ashapefile) that represents the actual authoritative jurisdiction of thePSAP, which may then be provisioned in a geofence database. It isappreciated that a GIS file defining the authoritative jurisdiction maybe saved in one or more industry-acceptable formats such as a shapefile,a GeoJSON file, KML file, etc. In some embodiments, the GIS fileincludes one or more features such as points, lines, polygons, density,and other shapes. A GeoJSON is open standard GIS file representinggeographical features and non-spatial attributes based on JavaScriptObject Notation. Some features include points (such as addresses andlocations), line strings (streets, highways and boundaries), polygons(countries, provinces, tracts of land), and multi-part collections ofthese types. A Keyhole Markup Language (KML) file includes geographicannotations and visualization on internet-based maps on Earth browsers.A shapefile is a vector data format for storing the location, shape, andattributes of geographic features. A shapefile is stored in a set ofrelated files, each of which may contain one feature class (e.g., lines,points, polygons, etc.). In some embodiments, the shapefile is a filewith extension .SHP in ESRI file format where SHP is the featuregeometry, SHX is the shape index position and DBF is the attribute data.

Various embodiments of the geofence database are contemplated. In someembodiments, one or more databases are searchable using a PSAPidentifier, credentials, or other information. In some embodiments, anemergency location is searched through several geofences in the geofencedatabase. In some cases, the geofenced region is shrunk for ease ofstorage and to simplify calculations.

Digital Processing Device

In some embodiments, the platforms, media, methods and applicationsdescribed herein include a digital processing device, a processor, oruse of the same. In further embodiments, the digital processing deviceincludes one or more hardware central processing units (CPU) that carryout the device's functions. In still further embodiments, the digitalprocessing device further comprises an operating system configured toperform executable instructions. In some embodiments, the digitalprocessing device is optionally connected a computer network. In furtherembodiments, the digital processing device is optionally connected tothe Internet such that it accesses the World Wide Web. In still furtherembodiments, the digital processing device is optionally connected to acloud computing infrastructure. In other embodiments, the digitalprocessing device is optionally connected to an intranet. In otherembodiments, the digital processing device is optionally connected to adata storage device. In accordance with the description herein, suitabledigital processing devices include, by way of non-limiting examples,server computers, desktop computers, laptop computers, notebookcomputers, sub-notebook computers, netbook computers, netpad computers,set-top computers, handheld computers, Internet appliances, mobilesmartphones, tablet computers, personal digital assistants, video gameconsoles, and vehicles. Those of skill in the art will recognize thatmany smartphones are suitable for use in the system described herein.Those of skill in the art will also recognize that select televisions,video players, and digital music players with optional computer networkconnectivity are suitable for use in the system described herein.Suitable tablet computers include those with booklet, slate, andconvertible configurations, known to those of skill in the art.

In some embodiments, the digital processing device includes an operatingsystem configured to perform executable instructions. The operatingsystem is, for example, software, including programs and data, whichmanages the device's hardware and provides services for execution ofapplications. Those of skill in the art will recognize that suitableserver operating systems include, by way of non-limiting examples,FreeBSD, OpenBSD, NetB SD®, Linux, Apple® Mac OS X Server®, Oracle®Solaris®, Windows Server®, and Novell® NetWare®. Those of skill in theart will recognize that suitable personal computer operating systemsinclude, by way of non-limiting examples, Microsoft® Windows®, Apple®Mac OS X®, UNIX®, and UNIX-like operating systems such as GNU/Linux®. Insome embodiments, the operating system is provided by cloud computing.Those of skill in the art will also recognize that suitable mobile smartphone operating systems include, by way of non-limiting examples, Nokia®Symbian® OS, Apple® iOS®, Research In Motion® BlackBerry OS®, Google®Android®, Microsoft® Windows Phone® OS, Microsoft® Windows Mobile® OS,Linux®, and Palm® WebOS®.

In some embodiments, the device includes a storage and/or memory device.The storage and/or memory device is one or more physical apparatusesused to store data or programs on a temporary or permanent basis. Insome embodiments, the device is volatile memory and requires power tomaintain stored information. In some embodiments, the device isnon-volatile memory and retains stored information when the digitalprocessing device is not powered. In further embodiments, thenon-volatile memory comprises flash memory. In some embodiments, thenon-volatile memory comprises dynamic random-access memory (DRAM). Insome embodiments, the non-volatile memory comprises ferroelectricrandom-access memory (FRAM). In some embodiments, the non-volatilememory comprises phase-change random access memory (PRAM). In someembodiments, the non-volatile memory comprises magneto resistiverandom-access memory (MRAM). In other embodiments, the device is astorage device including, by way of non-limiting examples, CD-ROMs,DVDs, flash memory devices, magnetic disk drives, magnetic tapes drives,optical disk drives, and cloud computing-based storage. In furtherembodiments, the storage and/or memory device is a combination ofdevices such as those disclosed herein.

In some embodiments, the digital processing device includes a display tosend visual information to a subject. In some embodiments, the displayis a cathode ray tube (CRT). In some embodiments, the display is aliquid crystal display (LCD). In further embodiments, the display is athin film transistor liquid crystal display (TFT-LCD). In someembodiments, the display is an organic light emitting diode (OLED)display. In various further embodiments, on OLED display is apassive-matrix OLED (PMOLED) or active-matrix OLED (AMOLED) display. Insome embodiments, the display is a plasma display. In some embodiments,the display is E-paper or E ink. In other embodiments, the display is avideo projector. In still further embodiments, the display is acombination of devices such as those disclosed herein.

In some embodiments, the digital processing device includes an inputdevice to receive information from a subject. In some embodiments, theinput device is a keyboard. In some embodiments, the input device is apointing device including, by way of non-limiting examples, a mouse,trackball, trackpad, joystick, game controller, or stylus. In someembodiments, the input device is a touch screen or a multi-touch screen.In other embodiments, the input device is a microphone to capture voiceor other sound input. In other embodiments, the input device is a videocamera or other sensor to capture motion or visual input. In furtherembodiments, the input device is a Kinect, Leap Motion, or the like. Instill further embodiments, the input device is a combination of devicessuch as those disclosed herein.

Non-Transitory Computer Readable Storage Medium

In some embodiments, the platforms, media, methods and applicationsdescribed herein include one or more non-transitory computer readablestorage media encoded with a program including instructions executableby the operating system of an optionally networked digital processingdevice. In further embodiments, a computer readable storage medium is atangible component of a digital processing device. In still furtherembodiments, a computer readable storage medium is optionally removablefrom a digital processing device. In some embodiments, a computerreadable storage medium includes, by way of non-limiting examples,CD-ROMs, DVDs, flash memory devices, solid state memory, magnetic diskdrives, magnetic tape drives, optical disk drives, cloud computingsystems and services, and the like. In some cases, the program andinstructions are permanently, substantially permanently,semi-permanently, or non-transitorily encoded on the media.

Computer Program

In some embodiments, the platforms, media, methods and applicationsdescribed herein include at least one computer program, or use of thesame. A computer program includes a sequence of instructions, executablein the digital processing device's CPU, written to perform a specifiedtask. Computer readable instructions may be implemented as programmodules, such as functions, objects, Application Programming Interfaces(APIs), data structures, and the like, that perform particular tasks orimplement particular abstract data types. In light of the disclosureprovided herein, those of skill in the art will recognize that acomputer program may be written in various versions of variouslanguages.

The functionality of the computer readable instructions may be combinedor distributed as desired in various environments. In some embodiments,a computer program comprises one sequence of instructions. In someembodiments, a computer program comprises a plurality of sequences ofinstructions. In some embodiments, a computer program is provided fromone location. In other embodiments, a computer program is provided froma plurality of locations. In various embodiments, a computer programincludes one or more software modules. In various embodiments, acomputer program includes, in part or in whole, one or more webapplications, one or more mobile applications, one or more standaloneapplications, one or more web browser plug-ins, extensions, add-ins, oradd-ons, or combinations thereof.

Web Application

In some embodiments, a computer program includes a web application. Inlight of the disclosure provided herein, those of skill in the art willrecognize that a web application, in various embodiments, utilizes oneor more software frameworks and one or more database systems. In someembodiments, a web application is created upon a software framework suchas Microsoft®.NET or Ruby on Rails (RoR). In some embodiments, a webapplication utilizes one or more database systems including, by way ofnon-limiting examples, relational, non-relational, object oriented,associative, and XML database systems. In further embodiments, suitablerelational database systems include, by way of non-limiting examples,Microsoft® SQL Server, mySQL™, and Oracle®. Those of skill in the artwill also recognize that a web application, in various embodiments, iswritten in one or more versions of one or more languages. A webapplication may be written in one or more markup languages, presentationdefinition languages, client-side scripting languages, server-sidecoding languages, database query languages, or combinations thereof. Insome embodiments, a web application is written to some extent in amarkup language such as Hypertext Markup Language (HTML), ExtensibleHypertext Markup Language (XHTML), or eXtensible Markup Language (XML).In some embodiments, a web application is written to some extent in apresentation definition language such as Cascading Style Sheets (CSS).In some embodiments, a web application is written to some extent in aclient-side scripting language such as Asynchronous Javascript and XML(AJAX), Flash® Actionscript, Javascript, or Silverlight®. In someembodiments, a web application is written to some extent in aserver-side coding language such as Active Server Pages (ASP),ColdFusion®, Perl, Java™, JavaServer Pages (JSP), Hypertext Preprocessor(PHP), Python™, Ruby, Tcl, Smalltalk, WebDNA®, or Groovy. In someembodiments, a web application is written to some extent in a databasequery language such as Structured Query Language (SQL). In someembodiments, a web application integrates enterprise server productssuch as IBM® Lotus Domino®. In some embodiments, a web applicationincludes a media player element. In various further embodiments, a mediaplayer element utilizes one or more of many suitable multimediatechnologies including, by way of non-limiting examples, Adobe® Flash®,HTML 5, Apple® QuickTime®, Microsoft Silverlight®, Java™, and Unity®.

Mobile Application

In some embodiments, a computer program includes a mobile applicationprovided to a mobile digital processing device. In some embodiments, themobile application is provided to a mobile digital processing device atthe time it is manufactured. In other embodiments, the mobileapplication is provided to a mobile digital processing device via thecomputer network described herein.

In view of the disclosure provided herein, a mobile application iscreated by techniques known to those of skill in the art using hardware,languages, and development environments known to the art. Those of skillin the art will recognize that mobile applications are written inseveral languages. Suitable programming languages include, by way ofnon-limiting examples, C, C++, C#, Objective-C, Java™, Javascript,Pascal, Object Pascal, Python™, Ruby, VB.NET, WML, and XHTML/HTML withor without CSS, or combinations thereof.

Suitable mobile application development environments are available fromseveral sources. Commercially available development environmentsinclude, by way of non-limiting examples, AirplaySDK, alcheMo,Appcelerator®, Celsius, Bedrock, Flash Lite, .NET Compact Framework,Rhomobile, and WorkLight Mobile Platform. Other development environmentsare available without cost including, by way of non-limiting examples,Lazarus, MobiFlex, MoSync, and Phonegap. Also, mobile devicemanufacturers distribute software developer kits including, by way ofnon-limiting examples, iPhone and iPad (iOS) SDK, Android™ SDK,BlackBerry® SDK, BREW SDK, Palm® OS SDK, Symbian SDK, webOS SDK, andWindows® Mobile SDK.

Those of skill in the art will recognize that several commercial forumsare available for distribution of mobile applications including, by wayof non-limiting examples, Apple® App Store, Android™ Market, BlackBerry®App World, App Store for Palm devices, App Catalog for webOS, Windows®Marketplace for Mobile, Ovi Store for Nokia® devices, Samsung® Apps, andNintendo® DSi Shop.

Standalone Application

In some embodiments, a computer program includes a standaloneapplication, which is a program that is run as an independent computerprocess, not an add-on to an existing process, e.g., not a plug-in.Those of skill in the art will recognize that standalone applicationsare often compiled. A compiler is a computer program(s) that transformssource code written in a programming language into binary object codesuch as assembly language or machine code. Suitable compiled programminglanguages include, by way of non-limiting examples, C, C++, Objective-C,COBOL, Delphi, Eiffel, Java™, Lisp, Python™, Visual Basic, and VB .NET,or combinations thereof. Compilation is often performed, at least inpart, to create an executable program. In some embodiments, a computerprogram includes one or more executable compiled applications.

Software Modules

In some embodiments, the platforms, media, methods and applicationsdescribed herein include software, server, and/or database modules, oruse of the same. In view of the disclosure provided herein, softwaremodules are created by techniques known to those of skill in the artusing machines, software, and languages known to the art. The softwaremodules disclosed herein are implemented in a multitude of ways. Invarious embodiments, a software module comprises a file, a section ofcode, a programming object, a programming structure, or combinationsthereof. In further various embodiments, a software module comprises aplurality of files, a plurality of sections of code, a plurality ofprogramming objects, a plurality of programming structures, orcombinations thereof. In various embodiments, the one or more softwaremodules comprise, by way of non-limiting examples, a web application, amobile application, and a standalone application. In some embodiments,software modules are in one computer program or application. In otherembodiments, software modules are in more than one computer program orapplication. In some embodiments, software modules are hosted on onemachine. In other embodiments, software modules are hosted on more thanone machine. In further embodiments, software modules are hosted oncloud computing platforms. In some embodiments, software modules arehosted on one or more machines in one location. In other embodiments,software modules are hosted on one or more machines in more than onelocation.

Databases

In some embodiments, the platforms, systems, media, and methodsdisclosed herein include one or more databases, or use of the same. Inview of the disclosure provided herein, those of skill in the art willrecognize that many databases are suitable for storage and retrieval ofbarcode, route, parcel, subject, or network information. In variousembodiments, suitable databases include, by way of non-limitingexamples, relational databases, non-relational databases, objectoriented databases, object databases, entity-relationship modeldatabases, associative databases, and XML, databases. In someembodiments, a database is internet-based. In further embodiments, adatabase is web-based. In still further embodiments, a database is cloudcomputing-based. In other embodiments, a database is based on one ormore local computer storage devices.

Web Browser Plug-In

In some embodiments, the computer program includes a web browserplug-in. In computing, a plug-in is one or more software components thatadd specific functionality to a larger software application. Makers ofsoftware applications support plug-ins to enable third-party developersto create abilities which extend an application, to support easilyadding new features, and to reduce the size of an application. Whensupported, plug-ins enable customizing the functionality of a softwareapplication. For example, plug-ins are commonly used in web browsers toplay video, generate interactivity, scan for viruses, and displayparticular file types. Those of skill in the art will be familiar withseveral web browser plug-ins including, Adobe® Flash® Player, Microsoft®Silverlight®, and Apple® QuickTime®. In some embodiments, the toolbarcomprises one or more web browser extensions, add-ins, or add-ons. Insome embodiments, the toolbar comprises one or more explorer bars, toolbands, or desk bands.

In view of the disclosure provided herein, those of skill in the artwill recognize that several plug-in frameworks are available that enabledevelopment of plug-ins in various programming languages, including, byway of non-limiting examples, C++, Delphi, Java™, PHP, Python™, and VB.NET, or combinations thereof.

Web browsers (also called Internet browsers) are software applications,designed for use with network-connected digital processing devices, forretrieving, presenting, and traversing information resources on theWorld Wide Web. Suitable web browsers include, by way of non-limitingexamples, Microsoft® Internet Explorer®, Mozilla® Firefox®, Google®Chrome, Apple® Safari®, Opera Software® Opera®, and KDE Konqueror. Insome embodiments, the web browser is a mobile web browser. Mobile webbrowsers (also called microbrowsers, mini-browsers, and wirelessbrowsers) are designed for use on mobile digital processing devicesincluding, by way of non-limiting examples, handheld computers, tabletcomputers, netbook computers, subnotebook computers, smartphones, musicplayers, personal digital assistants (PDAs), and handheld video gamesystems. Suitable mobile web browsers include, by way of non-limitingexamples, Google® Android® browser, RIM BlackBerry® Browser, Apple®Safari®, Palm® Blazer, Palm® WebOS Browser, Mozilla® Firefox® formobile, Microsoft® Internet Explorer® Mobile, Amazon® Kindle® Basic Web,Nokia® Browser, Opera Software® Opera® Mobile, and Sony® PSP™ browser.

EXAMPLES

The following illustrative examples are representative of embodiments ofthe invention described herein and are not meant to be limiting in anyway.

Just In Time, an emergency response company, aids emergency serviceproviders (such as public safety answering points (PSAPs) and firstresponders) by gathering emergency data from a variety sources anddelivering the data directly to the emergency personnel. Traditionally,PSAPs are only technologically capable of receiving telephone calls withno additional data. Thus, when an emergency call is made to a PSAP froma mobile phone (with a dynamic and uncertain location), PSAP operatorsoften must speak directly to a person implicated in an emergency todetermine the person's location. Unfortunately, many people implicatedin emergencies are unable to articulate their location or do not evenknow it—and even if they do, the time spent articulating their locationto the PSAP operator can often be the difference between life and death.Similarly, PSAP operators and the first responders they send to respondto emergencies are forced to respond to emergencies with little or noinformation about the implicated persons (e.g., health data or medicalhistories) or emergency contexts (e.g., type of emergency, audio/videoof the surroundings, etc.). Just In Time knows how critical it is toquickly and accurately provide locations and situational/contextualinformation during emergencies to emergency service providers.

To aid emergency personnel, Just In Time provides an EmergencyClearinghouse (hereinafter, “clearinghouse”) that receives and storesdata and information from a plurality of sources, such as mobile phonesand mobile applications, IoT devices, intelligent vehicle systems andother electronic devices. While responding to an emergency, an emergencyservice provider can receive data relevant to the emergency directlyfrom the Emergency Clearinghouse. However, while this additionalinformation can improve an emergency service provider's ability torespond to an emergency, emergency service providers are often undertremendous pressure, and the decisions they make must be quick.Therefore, ineffective presentation of emergency data risks overwhelmingan emergency service provider with too much information or presentinginformation at the wrong time. Additionally, because some types ofinformation received by the Emergency Clearinghouse is sensitive (e.g.,medical history), it may be inappropriate to send certain types ofinformation to certain types of emergency service providers. Thus, tofurther aid emergency service providers, Just In Time provides anEmergency Data Management Portal (hereinafter, “management portal”),where an administrator can designate the appropriate access to membersof their organization emergency data (e.g., by defining roles andselecting appropriate data categories). When the ESP member logs-in, heor she accesses an Enhanced Data Display for data relevant to theemergency response.

Example 1

In one instance, PSAP B has opted to receive location and additionaldata from the clearinghouse and integrated the enhanced data displayinto existing call-taking desktop applications on PSAP B computers. Toactivate the integration, the administrator of PSAP B (who alsoadministers over PSAPs A and C) contacts Just In Time to verify hisidentity. After verifying his identity, Just In Time orally communicates(for added security) to the administrator of PSAP B a set of credentialsto use to access the management portal. Using the set of credentials,the administrator of PSAP B accesses the management portal and createsseparate keys for PSAP A, PSAP B, and PSAP C. Knowing that PSAP Bemploys a relatively flat hierarchy with only two roles within thePSAP—call-takers and supervisors—the administrator of PSAP B thencreates two roles under the key for PSAP B, one for call-takers and onefor supervisors. Although the administrator of PSAP B is excited to haveJust In Time's additional information provided to all of the employeesof PSAP B, he is wary of overwhelming call-takers. The administrator ofPSAP B decides that it would be best to select only locations andcontact information to be made accessible for the call-taker role,omitting other additional information such as health data, medicalhistory, and demographics. However, for the supervisor role, theadministrator of PSAP B selects all types of information in theclearinghouse to be made accessible. The administrator of PSAP B thenassigns the “Production” enabled environment to the key created for PSAPB, thereby activating the clearinghouse integration for live emergencycalls made to PSAP B.

Eric, a technology-loving middle-aged man from Pittsburgh, Pennsylvaniahas a Samsung Galaxy S8 mobile phone that he pairs with a Samsung GearS3 smartwatch. He has a health insurance app installed on his Galaxy S8,in which he has submitted his name, email address, home address, height,weight, and blood type. Eric also has an Amazon Echo smart home devicepaired with a Nest indoor smart camera installed in his home. The AmazonEcho is paired to his Galaxy S8. One day, while cutting open an avocado,Eric accidentally pierces his hand and, upon seeing blood gushing fromhis hand, he faints. Eric regains consciousness seconds after falling tothe ground and hears his Gear S3 chirping. His smartwatch has detectedhis fall through the use of sensors including an accelerometer and agyroscope (detecting a sudden acceleration and change in direction), andthe screen of the smartwatch is now asking Eric if he needs emergencyhelp. Eric, now bleeding profusely and thoroughly discombobulated,presses yes, which prompts his Galaxy S8 to initiate a 9-1-1 call, whichis channeled through Eric's Amazon Echo speaker system. Over the Echo'sspeakers, Eric hears a PSAP call-taker at PSAP B answer his emergencycall and begin to ask Eric what the nature of his emergency is.

Simultaneously with the initiation of the 9-1-1 call, Eric's Galaxy S8automatically generates an emergency alert associated with Eric's phonenumber and delivers it to Just In Time. The Emergency Clearinghouse thenautomatically gathers all information pertinent to Eric's emergency,including a device-based hybrid location from both Eric's smartphone andsmartwatch, Eric's current heartrate detected by his smartwatch, hisname, home address, email address, height, weight, and blood type fromhis health insurance app, and a live stream video of his home from hissmart camera. Although the information is gathered from differentsources, each piece of information is tagged with Eric's phone number toassociate the information with Eric and his emergency. Additionally, theEmergency Clearinghouse automatically tags the locations from Eric'ssmartphone and smartwatch and his home address from Eric's insurance appas “caller-provided locations,”; tags his height, weight, and blood typeas “medical information,”; tags his heartrate as “health data,”; tagshis name, email address, and phone number as “contact information,”; andtags the live stream of his home as “other data.”

Eric tells the PSAP call-taker that he has accidentally stabbed his handwith a knife and subsequently fainted. The call-taker assures Eric thatthey will get him help and asks Eric what his location is. Eric tellsthe call-taker that he is at home, but he is lightheaded from a loss ofblood and cannot recall his home address. While the call-taker asks Ericfor his home address, the call-taker also selects a Just In Time“Enhanced Data” button within the Enhanced Data Display on thecall-taker's computer, which sends an emergency data request to Just InTime that automatically includes the caller's (Eric) phone number andthe role of the call-taker (the “call-taker” role created by theadministrator of PSAP B at the Management Portal). The emergency datarequest also includes a clearinghouse access token automaticallygenerated for the PSAP call-taker. After receiving the emergency datarequest from the PSAP call-taker, the Emergency Clearinghouse thenreferences the “call-taker” role with the management portal to determinewhich types of additional data have been made accessible for the“call-taker” role by the administrator of PSAP B. In this case, as notedabove, only caller-provided locations and contact information wereselected to be made accessible for the “call-taker” role. Thus, althougha slew of other additional information is available for Eric'semergency, the Emergency Clearinghouse instantly returns only thelocations generated by Eric's smartphone and smartwatch and the homeaddress from Eric's insurance app along with Eric's name, email address,and phone number. However, this additional data gives the PSAPcall-taker exactly what he needs. The PSAP call-taker sees that thelocations generated by Eric's smart devices and the home addressprovided by the insurance app are in agreement. Without hesitation, andwithout waiting on Eric to recall his address, the PSAP call-takerdispatches an ambulance to Eric's home. The PSAP call-taker then tellsEric that the PSAP has Eric's home address on file and help is on theway.

Example 2

Three months after the events of Example 1, Eric uses a ridesharingmobile application (e.g., Uber or Lyft) to call a ride to work. Duringthe intervening months, the supervisors at PSAP B have been extremelysatisfied with Just In Time's additional emergency information, and haveurged the administrator of PSAP B to make all of Just In Time'sadditional information accessible to all of the employees of PSAP B,including those with the “call-taker” role. The administrator of PSAP Bobliged, again using his credentials provided by Just In Time to loginto the Management Portal, select to edit the key for PSAP B, selectthe “call-taker” role, and select to make all of types of information tobe made accessible for the “call-taker” role as well as the “supervisor”role.

Eric's ridesharing mobile app is also integrated with Just In Time andprovides information to the Emergency Clearinghouse regarding ridesfacilitated by the ridesharing app, such as personal information aboutthe drivers and passengers, user submitted locations, and the currentlocation of a ride. However, for liability reasons, the company thatprovides the ridesharing app has chosen that information provided by theapp only be made available for emergency alerts generated from theridesharing app. Unfortunately, during Eric's ride to work, another carruns a red light and collides with back left side of Eric's ride,directly hitting Eric. Eric's driver, a little shaken up but otherwiseokay, notices that Eric has been hit directly, is significantly injured,and has lost consciousness. The driver then immediately selects thepanic button within the ridesharing app, generating an emergency alertand initiating a 9-1-1 call to PSAP B.

A PSAP call-taker at PSAP B answers the 9-1-1 call and asks the driverwhat the nature of her emergency is. The driver tells the call-takerthat her car has been hit from the side and that her passenger (Eric)was hit directly and is in grave condition. The call-taker immediatelyselects the Enhanced Data button on her computer while asking the driverwhere her location is. The Emergency Clearinghouse instantly andautomatically gathers all of the information stored in the clearinghousepertaining to the emergency. Because the emergency alert was generatedfrom the ridesharing app and associated with Eric's ride, the emergencyalert is associated with both Eric's phone number and the driver's phonenumber. The Emergency Clearinghouse can then find all information withinthe clearinghouse associated with the driver's phone number and withEric's phone number, which includes (as noted above in Example 1),locations generated from both Eric's smartphone and smartwatch, Eric'scurrent heartrate detected by his smartwatch, his name, home address,email address, height, weight, and blood type from his health insuranceapp. The Emergency Clearinghouse also gathers the ride's currentlocation, the name of the passenger(s) and driver (Jessica), the ride'sorigin, and the ride's destination from the ridesharing app. TheEmergency Clearinghouse then returns all of the information to thecall-taker, because all types of information have been selected to bemade accessible for the call-taker role. The call-taker then asks if sheis speaking to the driver Jessica who responds in the affirmative. Thecall-taker then asks if Jessica is injured, to which Jessica says no.The call-taker then asks if the injured passenger is Eric, and if theirlocation matches the ride's current location provided by the ridesharingapp. Jessica responds yes to both.

Without hesitation, and without needing further confirmation from thedriver, the PSAP call-taker dispatches an ambulance to the ride'scurrent location. The call-taker then hits the ‘H’ button on hercomputer, which instantly highlights and moves Eric's health data to thetop of her screen. Because all of the information in the EmergencyClearinghouse has been returned to the call-taker, the call-taker cansee (from information generated by Eric's smartwatch) that Eric stillhas a pulse but that his pulse is weakening. The call-taker can also seeEric's blood type, provided by Eric's health insurance app, and tellsthe ambulance which type of blood to have on hand. The ambulance quicklyarrives at the scene of the crash with the knowledge that Eric is losingblood and prepared to administer a blood transfusion in the ambulance orupon arriving at a hospital. By instantly knowing Eric's preciselocation and health data, the emergency responders were able to saveEric's life.

Example 3

In order to provide access to the information stored within theclearinghouse to ESPs as quickly and easily as possible, Just In Timedevelops and provides an emergency response application in the form of awebpage or web application that is accessible through a standard webbrowser over public networks. Just In Time calls the web applicationNick Of Time. Any ESP administrator may request access to Nick Of Timeby navigating to the Nick Of Time website through any standard webbrowser and registering themselves and their ESP. The Nick Of Time webapplication is in communicably coupled to the Just In Time EmergencyClearinghouse and includes both a management portal and an enhanced datadisplay.

The administrator of a PSAP in Georgia, Joe, learns of the helpful andpotentially life-saving information stored within Just In Time'sclearinghouse—such as accurate emergency locations and medical histories(hereinafter, “emergency data”)—and that the PSAP may access theemergency data through a web application (Nick Of Time) without needingany special hardware or software. Accordingly, Joe types in the Nick OfTime URL into his web browser at his PSAP computer and loads the Nick OfTime website. The Nick Of Time website then presents to Joe a graphicaluser interface (GUI) and prompts Joe to submit information about himselfand his PSAP in order to register and request access to Nick Of Time.Nick Of Time requires Joe to enter his name, email address, password,and a non-emergency hardline phone number for the PSAP. Nick Of Timealso requires Joe to provide a geofence of the jurisdiction of the PSAP,which Joe can submit as a preexisting GIS file or generate using aninteractive map within the Nick Of Time GUI. Once Joe submits therequest, the information regarding Joe and his PSAP is sent to Just InTime for review and verification.

Once Just In Time verifies the information provided by Joe, Joe is sentan email from Just In Time notifying him that his request has beengranted. Joe then logs into Nick Of Time with his email address andpassword. Joe can then create Nick Of Time accounts for any number ofother members of his PSAP to use to access Nick Of Time. When Joecreates a new account for one of the Georgia PSAP call-takers, Jane, theNick Of Time web application prompts Joe to select a role for Jane. NickOf Time presents two default roles, the Admin role and the Agent role,for Joe to select from. The Admin role is allowed to receive all typesof emergency data from the Emergency Clearinghouse. The account that Joecreated for himself when he signed up for Nick Of Time was automaticallygiven the default Admin role because Joe is a verified PSAPadministrator. The Agent role is the default role given to members of anESP who are not administrators and is allowed to receive fewer types ofemergency data from the Emergency Clearinghouse than the default Adminrole. In this case, for example, the default Agent role is allowed toreceive a 911 caller's personal information (such as demographicinformation) and location but is not allowed to receive a caller'smedical information. Nick Of Time also presents Joe an option to createa new role within the management portal for the new account that he iscreating for Jane. Joe selects the default Agent role for Jane. However,Joe does want Jane to be able to receive medical information from theEmergency Clearinghouse. So, after Joe finishes creating the new accountfor Jane, Joe navigates to the management portal user interface withinNick Of Time and selects the default Agent role to edit the types ofemergency data that the Agent role is allowed to receive from theEmergency Clearinghouse. The management portal interface within Nick OfTime then displays all of the different categories of emergency dataavailable from the Emergency Clearinghouse and which of those differentcategories of emergency data have already been selected for the defaultAgent role. Joe sees that the personal information category of emergencydata (which includes data types such as name, age, and phone number) isalready selected for the default Agent role. Joe also sees that thelocation category of emergency data is permanently selected for thedefault Agent role and cannot be unselected. Joe then finds theunselected medical information category and selects the medicalinformation category to now be received by the Agent role. Joe also seesthat the contact information category of emergency data is unselected,and he decides to leave it unselected. Finally, Joe selects a savebutton to save his edits to the Agent role, which is no longer thedefault Agent role, because it has been customized by Joe.

Later, Jane logs into the Nick Of Time web application at her computerat the Georgia PSAP using a username and password sent by Just In Timeto Jane's email address, which Joe provided to Just In Time whencreating the new Nick Of Time account for Jane. When Jane logs in, NickOf Time references the management portal using Jane's email address anddetermines that Jane's account is associated with the Georgia PSAP andthat Jane's account has been given the Agent role that Joe hadcustomized. The management portal also provides Nick Of Time with tagsindicating which emergency data categories that Jane's role (thecustomized agent role) is allowed to receive from the EmergencyClearinghouse. Nick Of Time also communicates with Just In Time'sbackend system to receive a short-lived access token for Jane's loginsession. Nick Of Time then presents a dashboard to Jane through the NickOf Time GUI, where Jane can send requests for emergency data to theclearinghouse whenever Jane is responding to an emergency call. Janesoon receives an emergency call from a man named Steven, whose phonenumber is (555) 444-6666. To send an emergency data request to theclearinghouse, Jane simply types Steven's phone number into an entryfield within the dashboard and clicks submit. In response, Nick Of Timegenerates an emergency data request including Steven's phone number, theshort-lived access token, an identifier of the Georgia PSAP, and thetags indicating the emergency data categories that the customized Agentrole is allowed to receive. Nick Of Time then sends the emergency datarequest to Just In Time's Emergency Clearinghouse.

When the clearinghouse receives the emergency data request, theclearinghouse uses Eric's phone number to retrieve all of the emergencydata associated with Eric's phone number stored within theclearinghouse. The clearinghouse finds a current location for Eric sentto the clearinghouse from Steven's phone, in addition to Steven'sdemographics (age, height, weight, etc.), Steven's medical history, anda phone number for Steven's mother, who is listed as Steven's emergencycontact. The clearinghouse then uses the identifier of the Georgia PSAPto retrieve the geofence submitted by Joe during the Nick Of Timeregistration process. The clearinghouse then determines whether or notSteven's current location is within the geofence. For security purposes,the clearinghouse does not return emergency data to requesting partiesif a current location included in the emergency data is not within ageofence associated with the requesting party. However, theclearinghouse determines that Steven's current location is within thegeofence provided by Joe. The clearinghouse then uses the tagsindicating the emergency data categories that Jane's role (thecustomized Agent role) is allowed to receive to determine that Jane isallowed to receive location information, personal information, andmedical information. Thus, the clearinghouse returns Steven's currentlocation, Steven's demographics, and Steven's medical history to Nick OfTime to be displayed at Jane's computer. The clearinghouse does notreturn Steven's mothers phone number, however, because Jane's customizedAgent role is not allowed to receive contact information.

The Nick Of Time dashboard displays a graphical representation ofSteven's current location within a map and a textual description ofSteven's current location (e.g., latitude and longitude) within a textbox. The emergency data is returned in an instant after Jane sends theemergency data request. In response to receiving Jane's emergency datarequest for Steven's phone number, the clearinghouse also establishes awebsocket connection with Jane's computer and subscribes Jane's Nick OfTime account to Steven's phone number for the duration of Jane's loginsession. While Jane is talking with Steven, attempting to ascertain thedetails of his emergency, Steven's location moves, because it turns outthat Steven is actually inside of a moving vehicle. Five seconds afterJane received Steven's original location, the clearinghouse receives anupdated location from Steven's phone, which is associated with Steven'sphone number within the clearinghouse. Because the clearinghousesubscribed Jane's Nick Of Time account to Steven's phone number, theclearinghouse is able to instantly push updated emergency dataassociated with Steven's phone number (including Steven's updatedlocation) to Jane's computer through the Nick Of Time web application,without Jane having to send an additional emergency data request. Janecontinues to receive updated locations for Steven from the clearinghouseevery five seconds until the vehicle that Steven is in comes to a stop.Jane then dispatches emergency help to Steven's most recent location,and the emergency help is able to find Steven at the location that Janeprovided them.

What is claimed is:
 1. A system for managing access to emergency datafor emergency service providers, the system comprising: (a) a managementportal implemented as one or more software modules on a computing systemcomprising a processor and a non-transitory computer readable storagemedium and configured to: (i) establish a first role that is assignableto one or more users associated with an ESP; and (ii) define a first setof emergency data fields that is accessible by an ESP user assigned thefirst role; (b) an emergency response application implemented as one ormore software modules on a computing system comprising a processor, adisplay, and a non-transitory computer readable storage medium andconfigured to: (i) log the ESP user assigned the first role into theemergency response application; (ii) generate an emergency data requestcomprising an identifier associated with an emergency alert; and (iii)transmit the emergency data request to an emergency management system;and (c) the emergency management system, implemented as one or moresoftware modules on a cloud computing system comprising a processor anda non-transitory computer readable storage medium and configured to: (i)receive the emergency data request from the emergency responseapplication; (ii) gather, using the identifier, emergency datacorresponding to the first set of emergency data fields and associatedwith the emergency alert; and (iii) securely transmit the emergency dataassociated with the emergency alert to the emergency responseapplication for display on the computing system in (b).
 2. The system ofclaim 1, wherein the management portal is further configured to: (a)establish a second role that is assignable to one or more users withinthe ESP; and (b) define a second set of emergency data fields that isaccessible by any ESP user associated with the second role, wherein thefirst set of emergency data fields and the second set of emergency datafields comprise different sets of emergency data fields.
 3. The systemof claim 2, wherein the second set of emergency data fields is definedfrom a plurality of emergency data fields.
 4. The system of claim 1,wherein the first set of emergency data fields is defined from aplurality of emergency data fields.
 5. The system of claim 1, whereinthe first set of emergency data fields is defined using one or moreemergency data categories, wherein each emergency data categorycomprises two or more emergency data fields.
 6. The system of claim 5,wherein the one or more data categories comprises a data source, whereinthe first set of emergency data fields accessible by the ESP userassigned the first role excludes one or more data sources.
 7. The systemof claim 5: (a) wherein the emergency data request comprises one or moretags indicative of the first set of emergency data categories; and (b)wherein the emergency management system is further configured todetermine the first set of emergency data categories using the one ormore tags.
 8. The system of claim 1, wherein the emergency responseapplication is further configured to: (a) detect the emergency alertwhen the emergency alert is received by the ESP; and (b) autonomouslygenerate the emergency data request in response to detecting theemergency alert.
 9. The system of claim 1, wherein the emergencyresponse application is further configured to generate the emergencydata request in response to input by the ESP user at the emergencyresponse application.
 10. The system of claim 1, wherein the managementportal further comprises a graphical user interface shown on a displayof the computing system on which the management portal is implemented,and wherein the management portal is further configured to: (a) displaythe plurality of emergency data fields or a plurality of emergency datacategories on the display; and (b) receive selection of the set ofemergency data fields or one or more emergency data categoriescomprising the set of emergency data fields from the plurality ofemergency data fields or the plurality of emergency data categories byan administrator of the ESP through the graphical user interface. 11.The system of claim 1, wherein the first set of emergency data fieldscomprise one or more anchor data fields that cannot be deselected. 12.The system of claim 1: (a) wherein the emergency data request comprisesan identifier of the first role; and (b) wherein the emergencymanagement system is further configured to determine the set ofemergency data fields that is accessible to the ESP user assigned thefirst role by querying the management portal using the identifier of thefirst role.
 13. The system of claim 1, wherein the emergency responseapplication is further configured to detect the emergency alert, whereinthe emergency alert is generated by an electronic device and wherein theidentifier associated with the emergency alert is a phone numberassociated with the electronic device.
 14. The system of claim 13,wherein the emergency alert is an emergency call made to the ESP by theelectronic device.
 15. The system of claim 13, wherein the electronicdevice is a vehicle device, wearable device, smartphone, or Internet ofThings (IoT) device.
 16. The system of claim 1, wherein the first set ofemergency data fields that is accessible to the ESP user assigned thefirst role comprises location data, and wherein the emergency dataassociated with the emergency alert comprises a location.
 17. The systemof claim 1, wherein the emergency management system is furtherconfigured to: (a) obtain a location associated with the emergencyalert; (b) access a geofence associated with the ESP; (c) determine ifthe location falls within the geofence associated with the ESP; and (d)securely transmit the emergency data corresponding to the first set ofemergency data fields and associated with the emergency alert only ifthe location is determined to fall within the geofence associated withthe ESP.
 18. The system of claim 1, wherein the emergency managementsystem further comprises a software module configured to ingest datafrom at least one electronic device associated with the emergency alert.19. A system for managing access to emergency data for emergency serviceproviders, the system comprising: (a) a management portal implemented asone or more software modules on a computing system comprising aprocessor and a non-transitory computer readable storage medium andconfigured to: (i) establish a first role that is assignable to one ormore users associated with an ESP; and (ii) define a first set ofemergency data fields that is accessible by an ESP user assigned thefirst role; and (b) an emergency response application implemented as oneor more software modules on a computing system comprising a processor, adisplay, and a non-transitory computer readable storage medium andconfigured to: (i) log the ESP user assigned the first role into theemergency response application; (ii) generate an emergency data requestcomprising an identifier associated with an emergency alert; (iii)transmit the emergency data request to an emergency management system;(iv) receive emergency data corresponding to the first set of emergencydata fields and associated with the emergency alert; and (v) display theemergency data on the computing system.
 20. A system for managing accessto emergency data for emergency service providers, the systemcomprising: (a) a management portal implemented as one or more softwaremodules on a computing system comprising a processor and anon-transitory computer readable storage medium and configured to: (i)establish a first role that is assignable to one or more usersassociated with an ESP; and (ii) define a first set of emergency datafields that is accessible by an ESP user assigned the first role; and(b) the emergency management system, implemented as one or more softwaremodules on a cloud computing system comprising a processor and anon-transitory computer readable storage medium and configured to: (i)receive an emergency data request comprising an identifier associatedwith an emergency alert from an account of an ESP user assigned thefirst role at the ESP; (ii) gather, using the identifier associated withthe emergency alert, emergency data corresponding to the first set ofemergency data fields and associated with the emergency alert; and (iii)securely transmit the emergency data to the ESP for display on acomputing system.